Re: new win32 port of GTK http://introspector.sourceforge.net/dia_win32.htm

[Owen Taylor <otaylor redhat com>]

Hans Breuer <Hans Breuer org> writes:

> At 11:38 07.01.03 -0500, Owen Taylor wrote:
> >
> >James Michael DuPont <mdupont777 yahoo com> writes:
> >
> >> --- Owen Taylor <otaylor redhat com> wrote:
> >> > 
> >> > James Michael DuPont <mdupont777 yahoo com> writes:
> 
> [...]
> 
> >> > I'm am also concerned about the difficulty of compiling the Win32
> >> > port of GTK+ currently, but any fixes (and the biggest one is
> >> > simply documentation) absolutely need to be done in conjunction 
> >> > with Tor.
> >> 
> >> Tor knows about my issues, and hans as well. 
> >> 
> Tor and me have tried to explain our build environmnts in :
> http://cvs.gnome.org/bonsai/cvsblame.cgi?file=glib/README.win32
> 
> If there is something unclear if using a similar environment we 
> would probably both try to explain better :)

Certainly any docs are a good thing. :-). Still, I'm not sure
that document would allow someone without a lot of experience
to get an auto* build of GLib-GTK+ going. Harder for me to 
say about a MSVC build.

> But at least me does not know nothing about debian and cross 
> compiling for windoze, it's simply out of my business.

[...]

> > - Being able to compile our libraries easily is important;
z> >   if the libraries are hard to compile, then we will get
> >   less contributions.
> >
> Owen, how do you think cross-compiling does fit into this picture ?
> MHO still is that the improvement of the win32 port (in the Gtk sense)
> does require to build or at least debug on win32. 
> And I'm still assuming that most interested win32 developers do have 
> access to the Micro$oft tool chain.

Clearly, both MSVC and GCC have advantages:

 MSVC:

  - Use familiar tools for Win32 programmers
  - No complex cygwin environment to set up
  - Better debugging/profiling capabilities
  - Possibly slightly better code generation 
  - No need to deal with the extreme slowness of auto* and libtool
    on a platform without vfork.

 auto* + GCC:

  - Shares much of the build structure with Unix
  - Same compiler as on Linux
  - Zero cost (MSVC isn't expensive on the scale of programming
    tools, but it's not zero cost)
  - Support a free software environment

But despite that, I frankly don't know whether supporting both 
makes sense. It makes a complex situation even more complex and 
intimidating to:

 - have docs and makefiles for both
 - to not know which one works at the moment
 - etc

If we were going to drop one, it would probably have to be MSVC,
for the free software / zero cost issues. (And because Tor uses
auto* and GCC.) As long as we have someone willing to maintain
the MSVC makefiles, it probably doesn't make sense to remove
them. But if we were to make building on Win32 part of the
release criteria, I think we'd need to pick one method 
or the other as the official method of compiling GTK+ for Win32.

How does cross compilation fit into the picture? I don't think 
I ever expect to to be the primary method of building GTK+
for Win32; people who want to hack GTK+ for Win32 will
generally be people running under Win32.

On the other hand, it does have certain advantages:

 - It's attractive way of doing automated rebuilds, because
   of the better batch facilities of Linux/Unix and because of 
   the much greater speeds of auto* on Linux/Unix.

 - It avoids a lot of dealing with Cygwin, which is the
   most horrific part of dealing with auto* on Win32.

As long as it's easy to support cross compilation, and I think it will
be easy to support as long as we are supporting auto* native on Win32,
then I think it makes sense to suport cross compiation.

Regards,
                                        Owen