On Fri, Oct 16, 2009 at 6:43 AM, Tor Lillqvist <tml@xxxxxx> wrote: >> 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? > These are the sizes of the working binary dll not include extras like gio.dll and related libraries. Simply the glib.dll. The glib came out of a build I did a ways back using pretty much the standard build process (configure make and make install) on the way to building gedit. I didn't change anything here so it was probably O2. Looking at your version though from gtk.org glib-2.0.0.dll is over 1 Mb, how are you building that? Are the debugging symbols in there? On the Visual Studio platform using O2 optimization level glib.dll from my project from the Microsoft compiler is 304 KB glib.dll from my project from the Intel compiler is 192 KB Note that with the intel and microsoft toolchain, the debug symbols are stored externally in a separate database which can be linked in at run time or discarded. >> 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.) > Very cool, so will I need to build these or not? Does cairo still require them? >> 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 thought that was what glibconfig.h would be used for. If not, why have two config files? >> I chose to use the latest pcre rather than whatever comes with glib. >> It seemed appropriate. > > Please file a bug with a patch then? Why is this included with the library anyways, why not just have it as an external dependency and delete it from glib? > >> 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.... Hmm, I see what you mean. Here is my consideration though, the directory layout of glib is not terribly conducive to being built inside of visual studio. Because there are a large number of dependences sharing header files it became easier to just pull the necessary public headers out of the distributed layout and drop them into a single include directory located at $(SolutionDir)include This is this way because visual studio does not export public include directories from dependencies (although it does export linker dependencies) This has some ramifications of course since it becomes harder to create patches against upstream versions (need to do it basically on a file-by-file basis and glue the results afterwards). But it makes the build and dependency management process a billion times easier. I have tried to do it a couple times against a packages original directory layout and had major complexity issues. That said maybe I (or someone else...hint hint) could write a "make dist-windows" target into the autotools stuff which creates a zip file and bundles a windows compliant config.h. The zip would contain only those files necessary in a windows build in a predictable directory layout. I currently have /include /source/applications/$ProjectName (If project is an application) /source/library/$ProjectName (If project is a library) /project/$ProjectName/$ProjectName.vcproj You'll note that I didn't use names like src or lib or bin because I want to emphasize that this is a departure from the FHS world. Such a zip would fit seamlessly into my build environment. Tracking upstream becomes it's own task, but this is likely going to remain that way anyways so perhaps a bit of deliberateness is appropriate. Having a common distribution of the build environment makes it profoundly easier to use it. Just look at how QT is distributed and how it supports visual studio. >> I could certainly use some help. > So could we, for actual Windows-specific bugs and misfunctionality in > the code. Yes, I concur. As a side note, who generally works on the win32 stuff other than yourself? > 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. I will certainly make everything I do available to upstream -- Ted Bullock <tbullock@xxxxxxxxxxx> _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
