RE: Gtk+ 3.0 and MS Windows

[Fan Chun-wei <fanc999 yahoo com tw>]

Hello Mikhail,

> 1. I'll make corrections it if you didn't make it ahead of
> me.
Please go ahead and do that, thank you! (I don't have a Wiki account yet!)

> 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.
Because it is shared with the GTK+/GNOME stack, from GLib onwards, so one 
can simply force-include it to take advantage of it-it was there since a
long time ago.

> 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.
The thing is, glibconfig.h is generated during ./configure... so it can't
be just placed there for OBS builds (it will be overwritten during the 
configure stage!).  This is why there is a (pre-generated) 
glibconfig.h(.win32) from the GLib source/binary tarballs from ftp.gnome.org-so MSVC builds can make use of immediately.  Note that during
VS builds of the source, glibconfig.h.win32 is copied to glibconfig.h 
before compiling GLib

> 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.
It is done differently on CMake-as CMake generates VS projects natively 
AFAIK... Again I really do appreciate the CMake concept (I build KDE 4.x on Windows too :), with VS, and you probably know that they use CMake), 
but there are others that are more skeptical about it.  Feel free to ask 
on the mailing list/IRC to see what people think about that, though, and 
perhaps people's attitude about it may change over time.  

Sorry for people here who use MinGW (a very commendable project), but I am 
one of those who (on Windows), will -much- prefer to build stuff in VS 
over MinGW, for performance and debugging reasons, and this is one of the 
big reasons why I took the role to maintain VS support for GTK+ stack 
(alongside with Hans Breuer who maintains the makefile.msc's throughout
the GTK+ stack-much credit and thanks goes to him for having GTK+-3.x 
running on Windows).  Building on Windows using autotools BTW takes way 
too much time for me :)

> 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.
The main thing about this, see my response for (4)...

Just to let you know, by the way, the latest stable GLib sources will only 
build out of the box for MSVC 2005 and later, and the latest stable GTK+ 
(2.24.x and 3.0.x) -will- require the latest stable GLib to build and run.

> 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.
I see, sorry I was not following the GTKMM development too much lately...

I think I will also attempt to build GTKMM 2.99.x/3.x when time allows, so
I might be able to make some reports there, if something regarding its 
build under VS is broken.:)

If other people are responding positively to your CMake proposal, please
also let me know.

> 
> 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+ :-)
No problem :)  Thanks.

God Bless,
Fan, Chun-wei