Re: gtkmm2.4 and MSVC (again)

[Cedric Gustin <cedric gustin swing be>]

Murray Cumming wrote:

> In the meantime, please make sure that any extra project file changes are
> in our CVS, so that we are starting at the same point. I have access to
> MSVC++ .Net 2003, so I might take a look if your own efforts don't reach a
> conclusion.

It would be nice to have fully working project files, including the 
examples. This means:

1. We must ASAP adopt some naming conventions for the DLLs and import 
libraries. With mingw32, the library names are determined by the 
configure script. Example : libglibmm-2.4.dll.a and libglibmm-2.4-1.dll

What shall we use for MSVC ? Right now, we have glibmm.dll and 
glibmm.lib. I propose to use glibmm-2.4.dll and glibmm-2.4.lib (problem: 
names longer than 8+3). I also think it would be nice to provide a 
resource file (glibmm-2.4.rc) generated by the configure script from 
glibmm-2.4.rc.in, that contains the library version

2. We should not use absolute paths for include or lib directories. On 
the other hand, we want to make sure that glibmm/gtkmm compile out of 
the box including the examples -> this means we must use some 
environment variables (macros). The GTK+ installer from gladewin32 
defines the GTK_BASEPATH. Should we use it in the glibmm/gtkmm project 
files ? And what about libsig++ (SIG_BASEPATH) or glibmm when building 
gtkmm (GLIBMM_BASEPATH) ? Or is there a way to directly define new 
macros in Visual Studio instead of using environment variables ?

3. What about using Makefiles and nmake instead of project files ? The 
advantage : people will be able to compile glibmm/gtkmm using the freely 
downloadable (and command line-based) MSVC developer tools.

I'm not a Visual Studio specialist and will let you decide...

Cedric