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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]