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

[Tor Lillqvist <tml iki fi>]

> The current port is difficult to use.

You mean difficult to build? I agree.

> It is based on the idea of downloading dlls from all over the net.

Hmm, to *build*, or to *use* the prebuilt DLLs I provide? To build it,
DLLs of dependent libraries aren't enough, you will need headers and
(import) libraries.

But the same is true when building GTK+ for Unix, too. Only on a Linux
box with typical developer packages installed can one be reasonable
certain that developer packages for libpng, zlib, iconv, etc are
present.

Even on something as common as Solaris 7 building a fully-working
(including i18n) GLib and GTK+ can be hard. One can imagine that more
exotic Unices have even more quirks.

> There is no place that you can get all the requirements for building
> GTk and *all* prerequisites.

> Many people who distribute the dlls dont put the source in the same
> place as required by the GPL section 3.

Please be specific what DLLs and what sources you are talking about
here. Do you mean that when distributing binaries of GTK+, one needs
to distribute the sources for, say, libtiff, from the same site?

> This problem is compounded by the fact that all the individual dlls
> are build by different people, and none of them are located in one
> spot.

So, your solution is to add another set of perhaps incompatible
library builds (DLLs or static) built by one more person (you)?

In fact, I think it's a *good* thing that if somebody else already
provides a build of some library, you use that instead of
unnecessarily rolling your own essentially identical build (unless you
intend to provide some new feature in said library, like I do in my
gettext build).

(Last year one person (rightly) complained about me distributing my
own builds of libiconv, libpng etc, when there were perfectly useable
Win32 builds available elsewhere. I agreed and stopped using and
distributing own builds of these and instead added links to those
"canonical" builds.)

> I am creating a static build, not a dll.

How do you handle installation-directory-independence? Currently it's
the DLL's startup functions (DllMain) that find out where GLib, GTK+
or Pango are installed, to find initialisation files, message
catalogs, dynamically loaded modules, etc. Message catalogs are
*important*.

Do you expect end users to install GTK+ in a fixed location that the
person who builds a distribution according to your standard decides? 
That is not a good idea on Windows. Or do you really expect Windows
*end-users* to want to build GTK+ themselves? Even seasoned corporate
NT administrators seldom have any ideas about building software from
source. Sad, but true.

(There is also the possibility to store the installation location of
each package in the Registry (see the docs for
g_win32_get_package_installation_directory()), but I would advice
against using that. The DllMain method is more elegant and enables
several independent installation of almost the same versions of some
software on the same machine without having to make sure the
installations look up differently named Registry keys.)

> That is why it is so hard to get all the sources. If we were to take
> the gpl by the letter, you need to provide all the sources of all
> the non-standard dlls that you have, the entire toolchain as I am
> doing it with the binaries.

The www.gimp.org/win32/downloads.html page *does* provide sources for
all the binaries on that site. (If something is missing, it is by
mistake.) But I am not going to provide copies of the sources (or
binaries) for gcc, binutils, awk, sed, perl, make, libtool, autoconf,
automake, and whatever else might be needed for a full auto*-style
build of GLib or GTK+.

If somebody (else) convinces me that the LGPL really requires it,
sure, I can have copies of the binary and source packages for libtiff,
libpng, etc there, too. But it does seem a bit silly, and causes
unnecessary maintenance troubles.

--tml