Following my patch for glibmm-2.3, I successfully compiled gtkmm-2.3 
(cvs) against gtk+-2.3.2 using mingw32-gcc (3.2.3). The worst part 
was definitively building gtk+-2.3.2 as no official binaries are 
currently provided. As gtk+-2.3 is rapidly changing when heading 
towards 2.4, my goal here is not to give a detailed description of 
the steps I followed but instead to submit a patch that makes the 
build of gtkmm possible with mingw32 as of today. 

As for gtkmm-2.2, a non-negligeable number of methods have been 
disabled on win32 because they are currently not available (dll 
exported) in gtk+-2.3. README.win32 has been updated to reflect the 
current status.

The biggest changes I made take place in the build_shared directory. 
The building process is getting quite complicated because it involves 
generated files (.h and .cc files coming from their .hg and .ccg 
counterparts in sublib/src) and extra files (.h and .cc source files 
located in sublib/sublibmm). All those files can either be platform-
independent (general) or platform-specific (win32/posix). And there 
is now the "deprecated" category !

To make this work and install correctly on win32, I had to introduce 
new variables in Makefile_build_gensrc.am_fragment. This file is now 
an interface between the sublib-specific list of files defined in the 
Makefile_list_of_hg.am_fragment's and the generic 
Makefile_build.am_fragment and Makefile_gensrc.am_fragment, to be 
included in sublib/src/Makefile.am and sublib/sublibmm/Makefile.am, 
respectively (where sublib can be atk, pango, gdk, gtkmm, ...). I 
added a lengthly description of these new variables introduced in 
Makefile_build_gensrc.am_fragment. I'm aware that these are not small 
changes but I think this adds some more genericity to the all 
building process.

I attached my patch against the current CVS along with the revamped 
Makefile_build_gensrc.am_fragment for people who want to have a look. 
See the patched ChangeLog for details.

Created attachment 23924 [details] [review]
Patch that fixes compilation of gtkmm-2.3 on win32 (mingw)

Created attachment 23925 [details]
The revamped Makefile_build_gensrc.am_fragment

> As gtk+-2.3 is rapidly changing when heading towards 2.4.

The API is not, I think, so it should not be a problem.

> non-negligeable number of methods have been 
> disabled on win32 because they are currently not available (dll 
> exported) in gtk+-2.3

I hope that that is being dealt with elsewhere, like before.

I trust you with the build changes, based on your previous stuff. I
know that it's getting complicated - and I don't think the deprecated
variables are even used yet. We'll make it better later if we think of
a way.

Please feel free to commit this. Thanks for the great work and the
explanation.

I will commit this as soon as I have a successful build of the latest 
glibmm and gtkmm against libsigc++2. Right now, I have this GdkColor 
const correctness error that was just reported by Alberto Paro on the 
mailinglist. Apart from that, compilation is running fine, so I hope 
we can have a simultaneous release of gtkmm-2.4 on both (l)unix and 
win32 (if a stable win32 port of gtk+-2.4.0 is immediately available).

glib-2.3.3 and gtk+-2.3.4 were released today but the future does not 
look good for the port of gtk+ on the win32 platform. glib does not 
compile at all on win32 as a bunch of posix-related functions were 
recently added, without providing win32 replacements. 

I also found this bug report

http://bugzilla.gnome.org/show_bug.cgi?id=134813

which is not promising.

I guess I'll wait till the next unstable release and see if the 
situation somewhat improves before submitting my patches for glibmm 
and gtkmm. 

> Right now, I have this GdkColor const correctness error that was
just > reported by Alberto Paro on the mailinglist.

In general, you need GTK+ from CVS to build gtkmm from cvs, during the
unstable phase.

> the future does not look good for the port of gtk+ on the win32 
> platform. glib does not compile at all on win32 as a bunch of 
> posix-related functions were recently added, without providing win32
> replacements. 

Hmm, where are the emails/bugs about this?

Ok, I tried CVS. glib is now fine, thanks to yesterday commits by Hans
Beuer. See this thread
http://mail.gnome.org/archives/gtk-devel-list/2004-February/msg00190.html
for details, bugzilla ref numbers, ... 

Same thing for pango and atk. Looks good. 
I then successfully compiled CVS glibmm. 

I'm currently fighting with CVS gtk+ (which, as of today, fails
miserably with mingw32-gcc) and I'm closely following the ChangeLog
for commits by either Hans Beuer or Tor, but I don't think Tor has
tried to build gtk+ recently with mingw32-gcc (see bugzilla #134813)

> I'm currently fighting with CVS gtk+ (which, as of today, fails
> miserably with mingw32-gcc)

It's great that you got this far, but you should not keep any problems
to yourself. Please post to a mailing list about this - maybe someone
knows a solution already or wants to find one. 

I managed to compile glib, atk, pango, gdk and gtk from CVS. A few 
fucntions were not DLL exported. I will submit entries on bugzilla in 
the next few days to fix these problems (like I did for gtk+-2.2). 
glibmm and gtkmm compile successfully. The helloworld example runs 
fine. However, I have problems with all examples that call 
show_all_children. No widget is shown and the program exits 
immediatly (without error, return status 0). Changing this to 
show_all somewhat fixes the problem but of course, it removes all 
recursivity !

Any idea ? 

P.S. : I attach a screenshot of the new (wimpified) gtkmm folder 
chooser.

Created attachment 24950 [details]
The new folder chooser from gtkmm on win32

Well done. No idea about the show_all_children() though it's worth
noting that it is a gtkmm method, not a GTK+ method. It's implemented
with C functions but it can also be implemented with the STL-style
children() container. You might try that.

The show_all_children bug disappeared when I updated to the latest 
libsigc++ CVS. 

gtkmm cvs HEAD is now compiling fine on win32. All examples seem to 
be functional (including gtk-demo). It also seems that work has 
resumed on the win32 port of gtk+ (see recent posts on the gtk-devel 
list). I'm trying to track win32-related changes on the glib, atk, 
pango and gtk+ CVS. All glib, atk and pango functions are now 
available in their -mm counterparts on win32. Same for gtk+/gtkmm 
(with the usual exceptions of plug and socket) ! A few gdk functions 
are currently not implemented on win32 (mostly related to 
display+cursor) and are not wrapped in gdkmm. I updated the 
README.win32 accordingly.

Before I commit my changes, I need to test the generated tarball 
(make dist) on linux (on my fedora core 1 box). 

I also need some extra info on the build process of deprecated files. 
Currently, generated deprecated files (combo.(h|cc)g for example) are 
compiled and installed while extra deprecated files (like 
toolbar_elements) are neither compiled nor installed. Is that 
supposed to be the correct behavior ?

Ok, here is a new (very long) patch to make gtkmm CVS build on win32 
with mingw32 against glib, atk, pango and gtk+ 2.4 HEAD (as of 
20040308). The good news is that it works beautifully, thanks to the 
amazing work of the gtk+-on-win32 developers in the last few days. 
Turns out all gtk+ functions are now available from gtkmm on win32 
(with the exception of Plug and Socket of course !). 

Now, I hope this patch does not break anything on (l)unix. I tested a 
generated tarball on my Fedora box and it seems to work as expected. 
I would be glad if somebody else could patch his own CVS checkout and 
test it with another linux distribution for example. I will then 
commit my changes.

See the patched ChangeLog for details.

Created attachment 25382 [details] [review]
Patch that fixes compilation of gtkmm-2.3 on win32 (mingw)

It seems fine in my checkout. Please commit.

I committed it accidentally myself.

Closing. Well done and thanks for the hard work.