> * 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 _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
