Re: [gtkmm] Win32 development installation instructions

[Robert <morelli cs utah edu>]

We're veering a little off gtkmm here,  but I think this is on
topic because anyone who wants to port to Windows has to figure this 
stuff out (or at least grope their way toward some subset of it that 
works) and there's very little in the way of explanation anywhere else.
Truth is,  it's really just a bummer.

When I get this stuff straight,  I'm thinking of  summarizing it on a 
web page as a public service,  if someone else out there doesn't do it. 
Of course,  it should really be integrated with the documentation for 
the tools and environments themselves ...

... and we haven't even discussed the complications of dll hell under 
Windows,  or (as you point out) Dev-C++,  or for that matter using 
Microsoft development tools,  ...

On Wed, 2004-03-10 at 04:10, Cedric Gustin wrote:
> At 11:36 AM 3/10/2004, Robert wrote:
> 
> >I'd appreciate any comment on the remarks below,  to make sure I've
got
> >this right.
> >
> >It seems to me that there are at least 4 different possible
> >configurations that people might mean when they loosely refer to
> >"cygwin" under Windows.
> >
> >1.  The cygwin development environment which resembles a unix
> >environment in which you compile code containing POSIX calls and
which
> >produces executables depending on cywin.dll for POSIX emulation.
> 
> Right. The advantage of this setup : Most unix tools and libraries
compile 
> out the box (when they are not already available direcly from the
cygwin 
> website). Problem: I think you have to make your code GPL, because of
the 
> cygwin dll.
> 
> >2.  The cygwin environment as above with MinGW headers and libraries
> >installed in the cygwin environment.  Then using the gcc switch
> >mno-cygwin you compile code containing Win32 (but not POSIX) calls
> >and generate binaries that do not depend on cygwin.dll.
> 
> I have had many problems with this configuration. Last time I checked,
C++ 
> support was quite bad with -mno-cygwin. You also have to make sure
that you 
> never link against one of cyg*.dll.a import libraries. But I admit I 
> haven't tested this configuration for a few months.

Hmmm.  Problems with C++ support would be a show stopper for everyone
here.  When you say "Last time I checked" do you mean last time you 
checked some official documentation,  or do you mean last time you tried
to use this configuration on your own stuff and found it didn't work?

I'd really like to encourage the development and debugging of this
approach as the long term solution rather than 3.  It seems to me that
whatever problems there are currently with this approach are bugs,  
while problems with 3. are inherent to the differences between Windows
and unix file systems and will never go away.

> >3.  The cygwin environment as above with the MinGW distribution
> >separately installed.  Instead of using cygwin's gcc,  you put the
> >MinGW distribution's bin directory on your path ahead of cygwin's. 
Then
> >you use MinGW's compiler (with no mon-cygwin switch of course).  The
> >cygwin environment is now only a convenient set of unix command line
> >tools.
> 
> That's my current configuration and the one I use to build gtkmm and
pygtk 
> on win32. Works nicely for me with two drawbacks :
> 
> 1. You have to be extra carefull with the way your define your various
> *PATH* variables (\ vs / and spaces in directories) and your mount
points.

This is the setup I originally had.  I decided to move toward setup 2. 
because of drawback 1.,  which I found increasingly confusing the more
libraries I used.  

2. libtool support works but is really a mess (more on this later if 
> somebody is interested).

I haven't gotton this far.  libtool is a mess even without the confusion
of two file systems.  I won't ask you to take time to give information 
on this because I'm not using it.  But in general I'd encourage everyone
to be explicit and get information out there that could help other 
people avoid wasting time on the same things you've figured out.

> >4.  Cygwin is not installed.  MinGW is installed along with the MSys
> >command line tools.  This is like 3.,  except that the lighter weight
> >MSys tools are used instead of the Cygwin environment.
> 
> I don't like to have redundant installations.

Neither do I.  We already have a comprehensive Unix-like environment 
under Windows.  It's called Cygwin.  Cygwin is not hard to install.  
MSys is a fork of it whose purpose I don't quite get.

> In conclusion, I'll definitively have to test config 2 again.

I'd encourage reporting bugs back to the maintainers of the cygwin gcc.



> Cedric 
> 
>