Re: GTK+ on windows

[Ted Bullock <tbullock comlore com>]

On Fri, Oct 16, 2009 at 6:43 AM, Tor Lillqvist <tml iki fi> 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 comlore com>