Re: Autoconfiscation patch for GTK+ on Win32

[Tor Lillqvist <tml iki fi>]

Owen Taylor writes:
 > I'm planning to do a 1.3.10 release at the beginning of next week.
 > Should we be thinking about testing those tarballs on Win32 as
 > well as on X11, or are we still not at that point yet?

You mean testing a build from a tarball source before announcing the
release? I am not sure. It mostly is a resource question, do I or
somebody else happen to have time to test it at that point...

 > I think we can just do:
 > 
 >  gdktargetlib=libgdk-$gdktarget-1.3.la
 >  gtktargetlib=libgtk-$gdktarget-1.3.la

OK. BTW, is there a correct way to show a calculated default value in
the help string of AC_ARG_WITH calls?

AC_ARG_WITH(gdktarget, [  --with-gdktarget=[x11/linux-fb/win32] select GDK target [default=$gdktarget]], gdktarget=$with_gdktarget)

doesn't work, $gdktarget doesn't get expanded, and I don't see how it
could, as gdktarget is assigned its value only after the help test is
printed... at least with an autoconf 2.52 -generated configure.
configure --help prints:

  --with-gdktarget=x11/linux-fb/win32 select GDK target default=$gdktarget

(This is also a problem with the "--enable-debug=no/minimum/yes turn
on debugging default=$debug_default" message)

 > (Main problem here is that we probably can't depend on Perl
 > existing even for people building from CVS on Windows, so there is
 > a bit of a bootstrap problem.)

I do think that we could depend on Perl being there, we already do it
in gtk/makefile.msc, for instance. Building GTK yourself on Win32 will
always be something for the adventurous, who probably have Perl
already.

 > Why are we pulling in pangoft2 library here? This doesn't make
 > sense to me. (Also, it looks to me like PANGO_PACKAGES gets 
 > overwritten further down.)

Umm, I guess I was remembering my idea that pangoft2 could be viable
alternative to pangowin32 for gdk-win32. But I haven't pondered that
lately. I do remember that you didn't like the idea.

 > Do we have a gdk-pixbuf-win32 library? 

Umm, no.

 > GDK_PIXBUF_XLIB_EXTRA_CFLAGS/LIBS are for the gdk-pixbuf-xlib
 > library in contrib/ for using GdkPixbuf without Gdk.

I see. Will have to check whether it would make sense to have a
similar one for Win32.

 > > +  win32_cflags="$WIN32_CFLAGS"
 > > +  win32_ldflags="$WIN32_LDFLAGS"

 > What's the purpose of setting these variables ... they don't 
 > seem to be used anywhere.

Just copy-pasted from the X11 part, it sets x_cflags and
x_ldflags. (Now that you mention it, those don't seem to be used
either...)
 
 > Should these be added in configure.in? For X11, dependency libraries
 > definitely have to be in configure.in so they can make their way 
 > into the .pc file, but if we have reliable inter-library dependencies
 > on Win32 that may not be necessary.

Yup, I don't think it is necessary.

 > Perhaps we should have something like:
 > 
 >  G_WIN32_DEFINE_DLL_NAME (static, dll_name)

Yes, sounds like a good idea. Instead of "define" (which to me gives
the impression of something done at compile-time), maybe
G_WIN32_GET_DLL_NAME would be better? Or G_WIN32_GET_DLL_NAME_AT_RUNTIME, even?

 > (I guess the windows.h include is a bit of a pain ... is using
 > 'extern' or something like that to define the one function possible?

Yes, including windows.h just for a couple of typedefs and one
prototype might seem like overkill. OTOH, one really shouldn't be
duplicating a prototype from standard headers just to avoid an
include?

 > > +#if 1 /* def HAVE_WINSOCK_H */
 > 
 > Please fix :-)

Oops ;-)

 > Instead of this sort of hackery, why don't we just define
 > 
 >  _gtk_get_libdir()
 >  _gtk_get_localedir()
 >  _gtk_get_sysconfdir()
 >  _gtk_get_data_prefix()
 > 
 > in gtkmain.c, put them in gtkprivate.h and then use them where needed
 > instead of the macros. Yes, it is marginally less efficient, but
 > code cleanliness is more important.

OK.

--tml