(Cc:d to gimp-developer and gimpwin-dev)

Dominik Stadler writes: > As far as I can see the file libgimp/Makefile.in > contains filenames starting with "i:/target" and "g:/mingw.new/"

Ouch. Where the heck did those come from, I wonder. Makefile.in files aren't supposed to contain any host dependencies. Sigh, I'll have to do the "make distdir" once more and see if I can figure out what goes wrong.

Anyway, if you have a working automake-1.4 installation you can regenerate the Makefile.in files by running "automake-1.4 libgimp/Makefile" in the top-level directory.

Packaging source distributions is a pain in the rear for me... There are a couple of problems that I assume don't happen on Unix:

- For GLib and GTK+, it never works in the "docs" subdir, as that would require gtk-doc, texi2html or something which I don't have. I usually resolve this by removing "docs" from the top-level Makefile, and then copy the docs subdir from an official distribution into my source package.

- In GIMP it never works for the "intl" subdir, as that mess is differently handled when using GLib-2.x anyway, and no "intl" subdir should be there at all, AFAIK. (AM_GLIB_GNU_GETTEXT vs. AM_GNU_GETTEXT in configure.in). I usually resolv this by just removing "intl" from the top-level Makefile.

- Sometimes there are some problems in the "po" subdir also. I don't remember exactly, but one thing is that "make distdir" for some reason insists on creating *.gmo files, even if a normal "make" in the po subdirs creates *.mo files? But, the official source tarballs contain *.gmo files, too, so I guess this is OK.

In case somebody wonders why I bother at all doing own snapshot source distributions, it's because of the (L)GPL requirements. I don't want anybody to accuse me of not following those. Because of personal resource issues or random events I am usually not able to synchronize my binary builds with official source release schedules, I have to distribute source code corresponding to the binary builds I distribute. For instance, GLib and GTK+ 2.2.0 were released just before Xmas, but I didn't have time to do some essential bugfixes until during Xmas vacation.

Of course, an alternative could be to not distribute any binary packages at all, just commit stuff to CVS and let somebody else handle the Windows binary (and source) release packaging and distribution... After all, that's how it mostly works on Unix. Any volunteers?

--tml

(Again CC:ing to gimpwin-dev and gimp-developer. In general discussion like this should be on gimpwin-dev, and in the future, if gimpwin-dev is decommissioned, on gimp-developer.)

Dominik Stadler writes:

> if I can get this to compile successfully I will put up a webpage > that describes how to build GIMP on Windows using MinGW, so this > might easy some of the load on you.

Good...

> When I run automake from cygwin, I get lines with >
> @AMDEP_TRUE@DEP_FILES = ./$(DEPDIR)/gimp.Plo \ > @AMDEP_TRUE@ ./$(DEPDIR)/gimpbrushes_pdb.Plo \

> in the generated Makefiles. The items with @ produce errors > during running make.

I don't know exactly what causes this, but hopefully it goes away if you make sure you use automake 1.4(-p6). Unfortunately Cygwin (last time I looked) didn't provide an "automake-1.4" command but instead they have a wrapper script "automake" that runs either automake 1.7 or automake 1.4 (from /usr/autotool/devel/bin or /usr/autotool/stable/bin, respectively) depending on what version it thinks configure.in wants. As it says:

> This is automake-wrapper, which will hand off execution > to one of the two real versions listed above, depending > on the contents of configure.in/configure.ac. Since the > wrapper was called from within a directory in which those > files are not found, this generic 'version' message is > displayed.

Myself, I built automake-1.4-p6 and installed it so that it is found in PATH before Cygwin's one, to avoid this kind of problems.

--tml

Tor Lillqvist writes:
> Ouch. Where the heck did those come from, I wonder. Makefile.in files > aren't supposed to contain any host dependencies. Sigh, I'll have to > do the "make distdir" once more and see if I can figure out what goes > wrong.

Hmm. I don't really know what had happened, but if I run automake-1.4 with the flag --include-deps flag, it doesn't put those header dependency lines in the Makefile.in files. The strange thing is that it was only in libgimp/Makefile.in that there were lots of those header dependency lines. app/Makefile.in had one (1) !? But for instance in all the plug-ins/* directories the Makefile.ins did not have any of this cruft.

Oh well, there is now an updated gimp-1.2.4-tml-20030119-src.zip file downloadable. Nothing changed in it except the Makefile.in files, so if you just want them, download makefileins.zip.

--tml