Re: Patches and win32 build?

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

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

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,

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]