Re: Patches and win32 build?

[Cyrille Chepelov <cyrille chepelov org>]

Le Thu, Sep 25, 2003, à 01:56:34AM +0200, Hans Breuer a écrit:
> At 22:11 24.09.03 +0200, Cyrille Chepelov wrote:
> >Le Wed, Sep 24, 2003, à 07:13:52PM +0000, debacle a écrit:
> >> On Wed, Sep 24, 2003 at 03:14:03PM +0300, Steffen Macke wrote:
> >> > Sorry, this is my fault, component_feature.c is included
> >> > in the DLL - but I missed to copy the new shapes.
> >> 
> >> OK, thanks for the information.  If I send new patches to
> >> dia - and I plan to do so - (how) can I help making the
> >> patch win32-able?
> >
> >1. Stick to the published glib/gtk APIs
> >2. Never assume that the path separator is /, use the glib macros
> >3. when in doubt, assume the linker is dumber than your worst dreams.
> Which will also help on other 'dump' - i.e. non ELF - platforms. 
> [In fact I like the win32 linker, which somewhat enforces a clean 
>  dependency stack, no cross dependencies if you don't explicit 
>  want them.]

The win32 linker, enforcing a clean dependency stack ??? Uh. LINK.EXE
from Microsoft, perhaps, but I can assure you that the win32 *loader* is
happy to load certain spaghetti balls made of a mixture of Borland C++,
Intel C++ and Delphi (about a half-hundred DLLs total, absolutely messy,
you pull one DLL you get the 49 others free no matter what DLL you start
from. And of course if you dare recompile only a DLL, you risk shipping
a silently corrupt or silently vicious executable).

Point well taken for non-win32, non-ELF platforms (Solaris springs to
mind:
	3a. Do not assume that if liba requires libb and libb requires
	libd, you get libd into liba by just pulling -lb. You have to
	add -ld as well. 
we get about a report or two per release, due to ELF-induced linker
sloppiness.

For the Win32 linker, I was especially referring to global exported
variables, which maybe work in some conditions, but are a real PITA
compared to the way they can be exported with ELF. As you mentioned,
there is rarely a good reason for such a construction, so it's better to
stay away and stick with plain ' export "C" ' (whoops, C++ gene) functions and 
strict DAG import tree.

> >4. avoid anything else than pure C compilation and linking (e.g don't
> >   depend on sed pre-processing, or a large python post-processing)
> I'd pretty much like to replace Perl, which is at least required
> to build The Gimp and Gtk+ coming from cvs, with Python - but relying
> on one more scripting language should probably avoided.

well, I don't know why The Gimp and Gtk+ rely on perl, nor whether
that's justified, but I was mostly poking fun at myself for the dia
build process. I know it's a PITA to integrate a sed or perl or python
step in the MSVC environment, it's even worse with the Borland stuff I
use every weekday, and dia-on-MinGW is where it is.

> >8. This list is likely wrong and/or incomplete (especially as there are
> >   efforts to go to MinGW, which is a different toolchain compared to
> >   MSVC)
> But even MinGW inherits most of the portability problems out of 
> compatibility reasons. It even uses the same c-runtime.

True for the code itself, tough the build toolchain is fairly close to
the *nix build.

> 12. If you are forced to do non portable stuff, just do it. Don't
>     try to guess how to port it, but instead let it break at compie 
>     time. If the *nix codes intention isn't obvious some documentation
>     is much more helpful than hidden or halfway ported code.
>     IMO it is much simpler to fix when compiling on win32 fails instead 
>     of searching for (longtime) unnoticed portability problems at 
>     runtime.

Even better yet, use #ifdefs and #errors in an explicit way. When
testing for a potentially non-portable situation, avoid testing for the
platform but test for features instead (where applicable -- for stuff
which depends on the GDI, it'd be quite ridiculous to define HAVE_CREATEDC,
HAVE_RELEASEDC, HAVE_SELECTOBJECT et al.)

> 13. beware of gccism like 
> 	switch (x) {defaut : } 
>     does compile with gcc but msvc wants a statement even if it's 
>     an empty one : ;

in fact, beware of any gccisms at all. I don't see a compelling reason
why dia would require gcc intrinsics or __attribute__(I don't give a
damn about portability) hell.

avoid c89 constructs until you (Hans) say that the primary Win32
compiler is happy with them.

> 16. Declare all your functions befre using them. Note : this is not
>     a deficiency of the msvc compiler but some enforced coding style
>     through pragmas (-FImsvc_recommended_pragmas.h)

In fact, it's strongly recommended by c89 as well.

Happy to see that I wasn't too off-mark :-)

	-- Cyrille
	
--