RE: Gtk+ 3.0 and MS Windows

["Mikhail Titov" <mlt gmx us>]

Fan:

Thanks for the feedback!

1. I'll make corrections it if you didn't make it ahead of me.

2. Hmm.. so why all pragmas and defines from msvc_recommended_pragmas.h are not in property file (gtk+.vsprops)? It is just a few flags that turn all the noise on the console off.

3. As far as I understand it should be possible to safely add if/else preprocessor block to glibconfig.h.in so it will be MSVC-friendly in any case. It won't hurt other builds.

4. I saw your post in bugzilla about MSVC2010 files generated from template. Theoretically I guess it can be done with CMakeLists.txt as well.

5. In my understanding everyone is happy with autotools on all platforms but native Win32 builds. If so, will it hurt to keep few files around solely for native Win32 builds? Considering all pros for Win32 platform, I guess there should be no objections as they won't interfere with autotools.

I started it all just because I wanted to follow gtkmm development.
1. There are no official MSVC++ binaries for gtkmm 2.99
2. It is a pain to get custom ones especially for newcomers
3. There is no way to cross-build gtkmm for MS VC++ because of different name mangling
4. Library naming for gtkmm libraries is different than for gtk+ anyway. Furthermore (import) library name suffixes/postfixes can be easily changed in CMakeLists.txt  as I intentionally tried to mimic gtkmm appearance. And I guess few import library namings can be kept around by simple copying.

In overall, I'd like to see the possibility to stay up to date with gtkmm and all the stuff from git and build it as easy as typing nmake. I know this is the wrong list, but I had to start with gtk+ :-)

Mikhail


-----Original Message-----
From: Fan Chun-wei [mailto:fanc999 yahoo com tw] 
Sent: Sunday, April 03, 2011 11:14 PM
To: Mikhail Titov
Cc: gtk-list gnome org
Subject: RE: Gtk+ 3.0 and MS Windows

Hello Mikhail,

I read through your wiki post and I think the information you have there is quite helpful and informative for those intending to build GTK+-3.x with the OBS dependencies-thanks for that really, as it may not be clear on how to build the GTK+ stack with VS at the moment.  I think I should/would, if possible, also follow suit for writing a Wiki post on how to compile the GTK+ and perhaps the Clutter stack (GLib, Cairo, ATK, Pango, GDK-Pixbuf, GTK+ 2.24.x/3.x, JSON-GLib, Clutter) with their dependencies from VS 2008/2010 as far as possible, which means avoiding as much as possible to mix different CRTs, so it avoids the problem that you have mentioned (correctly) about usage of g_fopen etc.

This may take a while as 1)time constraints and 2)some packages are not yet shipping the VS 2008/2010 files due to different release cycles and/or some components are pending review.

Some things I would like to point out in your Wiki post, to clarify some issues:
1. There should no longer be need to change in the "additional include 
   path" for the $(GlibEtcInstallRoot)\include\Gdk-Pixbuf-2.0 as of 
   GTK+3.0.7, as that was updated upstream (thanks for pointing that out
   to me so that I could fix the discrepancy).
2. Seems that msvc_recommended_pragmas.h is not included in the OBS builds,
   that is the file which does the job to filter out non-essential VS
   warnings but keep people on the lookout for warnings which could likely
   cause trouble.  This is a file included in the source and binary 
   tarballs from ftp.gnome.org.
3. Since OBS binaries are cross-compiled for MinGW, the glibconfig.h was
   generated there, so that is why it is not VS friendly.  This may also
   be why pango-view looks for X, not native Win32/Cairo items (cross-
   compiler configure bug?)...
4. If people are wondering about the current *.sln/*.vcproj files, the
   file listings for compiling parts where the source files are 
   added/removed often are put into the template *.vcproj files when a
   stable/unstable source tarball is released, so this greatly simplifies 
   their maintenance-so the *.vcproj (or their templates) don't have to be 
   changed that often upstream, and the correct source files are placed in 
   the appropriate projects.  It was tml who came up with this strategy
   for the VS project files, so I carried on with that strategy.
5. Thanks much for the CMake items-but I am not entirely sure whether that
   will be accepted upstream in a review by other devs-and that is the 
   reason I said "no" for the moment-especially the naming would be an 
   issue for the *.lib files at least as there are many people using GTK+ 
   and its GNOME deps out there on Windows.

Hope this helps to clear some questions that may be involved, and thanks very much for the informative post.

God Bless,
-Fan, Chun-wei