Re: Patches and win32 build?

[Hans Breuer <Hans Breuer org>]

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.]

> 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.

> 5. Remember that configure is not used on Win32; rather, there is a
>   static config.h file. If what you do causes new tests to be added to
>   configure.in, you have to provide the outcome on the win32 platform
>   into the static config.h file.
> 6. Anything that touches Postscript and printing has chances to be
>   different.
> 7. Beware anything approaching advanced interaction with the window
>   manager -- the default unreplaceable window manager in Windows won't
>   do what you expect it to (or more politely, the flexibility X offers
>   and gtk thinly wraps doesn't map very well to the features offered by
>   Win32).
> 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.

> 9. Look at the intersection of contributors to gtk-win32 and dia.

10. if you expect files to be binary read tell the open
    function to do it. (O_BINARY or "rb"). There is the ugly Oxa ->
    0xd Oxa mapping otherwise. 
11. Don't rely on a specific Pango backends facility - here PangoFT2,
    instead of PangoWin32 if ever possible. It's not hard to implement
    the same stuff within win32 as done by FT2, but it appears almost
    impossible to get such patches accepted in Pango.
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.
13. beware of gccism like 
        switch (x) {defaut : } 
    does compile with gcc but msvc wants a statement even if it's 
    an empty one : ;
14. keep your alloc/dealloc pairs in sync g_new,g_malloc->g_free;
    malloc/free; xmlGetProp/xmlFree not always maps to the same
    runtime functions (this is true for *nix builds, too.)
15. don't unconditionally include non standard headers, e.g. unistd.h.
    If there is some HAVE_UNISTD_H or similar defined there is a
    reason for it.
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)
17. Don't assume hardcoded pathes - win32 gtk programs can be 
    installed anywhere without recompiling. There is some support
    in GLib to do this a well as in Dia, see lib/dia_dirs.[hc]
18. Try to avoid global variables, especially accross dynamic
    library boundaries. They are almost always bad coding style and 
    need special handling on win32.

Enough for now, although the list probably isn't complete yet,
as Cyrille already noted its not that difficult to produce
portable code out of the box. And fixing some glitches isn't
either.

        Hans

> If what you are doing is confined to new object types, or straight GUI
> work, and you don't do much file or network I/O and you do it carefully,
> your odds are good out of the box.
>
>       -- Cyrille

-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert