Re: GTK+ on windows

[Tor Lillqvist <tml iki fi>]

> * GNU gettext is hopeless and unportable in it's current state,

Well, "unportable" is perhaps a bit pessimistic, as it is possible to
build it both for 32-bit and 64-bit Windows and both builds seem to
work as far as I see. But it certainly is a pain, indeed. One can only
hope that if a 0.18 (or 1.0 even) version some day appears, the
codebase will have been significantly cleaned up.

> Some size comparisons:
> mingw glib (889 KB)
> msvc glib (304 KB)
> intel c glib (192KB)

Could you please explain exactly how you end up with these numbers?
Size of what? Size of the DLL? Sum of sizes of the "loadable"
segments? Or what? What glib version? The "official" (mingw-built)
glib DLL or a self-built one for mingw, too? What kind of optimization
options?

I am not doubting that Intel's compiler is better (for some value of
"good") than Microsoft's or gcc. But still the above numbers are
rather amazing. Strong claims need strong proofs;)

> The mingw result is a bit predictable considering it has to pull in
> half the universe to function outside of its natural habitat.

I don't immediately see what huge amounts of code a mingw-built glib
DLL would need to "pull in" that a MSVC- or Intel-built one wouldn't?
Certainly not enough to explain the huge differences above.

> Looking forward in time, dependencies like libjpeg, libtiff, libpng
> can probably be replaced with native gdi+ functionality to further
> reduce the complexity of the stack.

That possibility is already present. (And after bug #552678 was fixed
recently, it should even work. Fix has been committed to master and
gtk-2-18.)

> Also, #include "config.h" should be wrapped in HAVE_CONFIG_H
> everywhere....

No it should not. It simply is not supposed to be meaningful or
possible to build glib or gtk+ without a config.h, so it is pointless
to use HAVE_CONFIG_H, they just clutter the code.

> I chose to use the latest pcre rather than whatever comes with glib.
> It seemed appropriate.

Please file a bug with a patch then?

> Lastly, I'll throw up a google code project for the whole shebang if
> there is interest.

It would be more interesting to get separate patches for specific
issues into bugzilla than to have to look at a separate forked code
repository...

> I could certainly use some help.

So could we, for actual Windows-specific bugs and misfunctionality in
the code. Hopefully once you have your build system working nicely,
you will be able to help with that? Getting project files for building
the gtk+ stack with Visual Studio will certainly be nice! Hopefully
you will be interested in upstreaming such.

--tml