(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
