Re: [gtkmm] gtkmm-2.4 on MSVC

["Rene Jensen" <rj vivens dk>]

This is a long call-out for a skilled person to assist the msvc community.
Please read through..

> Yes, I am familiar with this, and it's one reason that I dislike the
> MSVC++ platform. As I say, the macros in libsigc++ are probably a good
> starting point.

The thing is that there is a huge audience screaming for an MSVC-built set
of DLL files, (which is not such a bad IDE at all once you, well, bleed your
wallet for it, and then are simply forced to like it.)

However a lot of us out here are simply ansi c++ programmers, with few
skills in m4/python and complex building processes. I have read the docs in
glibmm/docs/internal but I fear they only added to my utter confusion. It
should come as a surprise to nobody that wrapping a huge C library is a job
calling out for the use of script based wrapping, but unfortunately it does
sever a lot of us from the possibility to assist in development. Here's a
record of the trail of thoughts of a novice, they should explain why at
least I can't be of any help:

1) First I had to assure that the problem could be solved by adding a lot of
WINDLL_GTKMM macros in front of all classes. After a lot of recompiling, I
had an indication that it would help, though at the end some template issues 
still remained.
P.S. Remember to wrap all template-specializations too.

2) Making gtkmm ready for msvc is surely a massive change. It should not be
lost so I would want to apply it to the CVS-tree, not the stable packages.
Would anybody accept a patch touching practically all files without proper
testing in linux too? I tentatively tried to add a WINDLL_GTKMM macro in a 
few class declarations and running the configure script under MSys, but for 
some reasong that addition didn't make it into the created .h file.

3) Running autoconf and automake under MSys is not yet possible, so I would
have to install cygwin and do a little bit of path magic. I refused on
grounds that I just installed MSys NOT to have a huge cygwin install.
Besides I read somewhere else that building with cygwin required adding some
special flags to the compiler and a lot of other cygwin problems. Spend some 
time trying to find documentation of the state of affairs of autoconf and 
automake on MSys. They were apparently ready in a premature state. I backed 
out.

4) Had I decided to install cygwin, I would have been faced with the
decision of either adding the preprocessor macro WINDLL_GTKMM that Frank
Naumann mentioned, or writing some sort of m4 wrapper macro to do that. What
would the lead-developers have wanted, since their wish should be honored? 
Probably the m4 wrapper, which I was totally unable to write.

5) What 'layer' of macro code should I intercept in order to add
WINDLL_GTKMM to static functions? Or is this a highlevel configuration
issue? Does the buildprocess read some obscure config-file for things like
these? Reading through tons of lines of code I had no insight into didn't 
help.

6) There still seem to be an issue regarding data members of classes. Msvc
keeps warning that such a data member can't be used outside. Should all data
members be wrapped too?

Most of these points took several hours of reading, fumbling, installing,
reinstalling, attempted compiling etc. to arrive at. They were based on
scattered documentation which often lacked a date-of-creation or were
clearly obsolete.

My last attempt was abandoned silently, and I can imagine I'm not the only 
one who did that. Couldn't we please once and for all integrate MSVC into 
the gtkmm universe, now that Microsoft has finally provided a compiler that 
seems to be able to accomplish the job?




> I had hoped that there might be a better way now. I seem to remember
> something about being able to export everything automatically, but maybe
> that was a cygwin or mingwin thing.

Sadly to this date I haven't been able to find anything just resembling such
a feature, and I don't think writing Microsoft asking for something
compatible with --export-all would accomplish anything (:-/