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

[James Michael DuPont <mdupont777 yahoo com>]

--- Owen Taylor <otaylor redhat com> wrote:
> 
> 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.

I tell you, the MSVC stuff is dying out. There are very few people to
support the build system under windows, the MSVC compiler is not
helpfull, it changes its project system all the time. You can use the
auto-tools for windows building. 
 
> 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.

Well many people dont have a job that pays them to write gtk programs
for win32. They dont have money to buy msvc. 

Some people have a moral problem with installing MSVC illegally at
home.
I personally find it better to use linux at home, and cannot be
bothered to run windows.

> 
> 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.

Funny, the gcc for cygwin is build that way as well. ;)

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

I like cygwin, and use it at work. But dont have it at home.

> 
> 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.

that is good.

Remember :

Debian is built around the idea of easy compilation with dependancy
management.
Debian is built around the idea of maintaining patches outside of the
upstream, yet still keeping in synch.

The cost of supporting cross compilation is very little, i am
volunteering to support it. I also have one active member supporting me
and a couple of interested parties. That is why I asked for a link.

The auto* tools also work with the msvc compiler.

You guys have not even addressed the issue of the proliferation of the
dlls without sources, it might not be an issue for you, but it makes us
as a whole look bad.

mike


=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com