After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 445374 - Fixes for "make dist" from a clean/ro SVN tree
Fixes for "make dist" from a clean/ro SVN tree
Status: RESOLVED WONTFIX
Product: GIMP
Classification: Other
Component: General
git master
Other Linux
: Normal minor
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2007-06-08 05:38 UTC by Daniel Richard G.
Modified: 2007-06-08 18:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch against current SVN (3.03 KB, patch)
2007-06-08 05:40 UTC, Daniel Richard G.
none Details | Review
Patch v1.1 against current SVN (3.55 KB, patch)
2007-06-08 06:12 UTC, Daniel Richard G.
none Details | Review

Description Daniel Richard G. 2007-06-08 05:38:08 UTC
This is what I want to be able to do:

  1. Check out GIMP SVN tree
  2. ./autogen.sh
  3. Make SVN tree read-only (chmod -R ugo-w ...)
  4. /path/to/configure in some build directory (out-of-source-tree build)
  5. make distcheck
  6. Exit status 0

Step 6 is the tricky one, natch.

Here are the changes needed to make this work:

* First, the po*/Makefile.in.in files need to be updated to the latest from intltool. The ones currently in SVN cannot handle *.gmo files in builddir when making a tarball, among other things.

* The new Makefile.in.in files will really, really need "stamp-it" stamp files in their respective directories. Otherwise, doing anything tends to cause makefile-regeneration loops. (I'm actually not sure where you frob these; I only know that it happens in the "stamp-it commands" stage at the end of a configure script run.)

* For some reason, I found it necessary to add desktop/gimp.desktop.in to POTFILES.skip in each of the po*/ subdirectories, otherwise "make check" (invoked as part of "make distcheck") fails, saying that "this file has translations but it's not being handled, blah blah." (It's actually gimp.desktop.in.in that has the l10ns.)

* There was an issue with the gtk-doc.make fragment's "html-build.stamp" rule in how it interprets the paths in HTML_IMAGES, in the case of devel-docs/libgimpwidgets/Makefile.am. This may have been fixed in more recent versions of gtk-doc, but that'll have to be confirmed. I used the version that came with my distribution; I've already hand-built too many libraries/tools to get to this point....

* Finally, there are the changes in the forthcoming patch. I'll describe those in the attachment comment.
Comment 1 Daniel Richard G. 2007-06-08 05:40:32 UTC
Created attachment 89586 [details] [review]
Patch against current SVN

app/Makefile.am:

* Adjust the ordering of gimp_console_2_3_LDADD to reflect inter-element build dependencies (libgimpmodule depends on libgimpbase, etc.).

* Add a rule so that the makefile knows how to obtain everything in gimp_console_2_3_LDADD, and so can build gimp-console from scratch (without needing to have built everything previously). We use $(filter) since ..._LDADD contains linker options et al. as well as libraries/objects.

themes/Default/images/Makefile.am:

* More s/srcdir/builddir/ tweaks. Here, it's especially needed, since these header files are evidently meant to be built by end users (they are not rolled into the tarball, and are listed in CLEANFILES).

data/tips/Makefile.am:

* gimp-tips.xml is a generated file; stay in builddir, refer to the file with $<, and use "--path $(srcdir)" so that xmllint can find the DTD.

autogen.sh:

* Touching config.h.in prevents that annoying autoheader invocation when you first start building in a freshly autogen'ed tree.

menus/Makefile.am:

* Same as the previous xmllint bit, only use $^ instead of $(menudata_DATA) so that Make automagically gives us an srcdir or builddir path for each file as appropriate.

plug-ins/pygimp/Makefile.am:

* Something to at least make it possible to build a tarball if you don't have PyGTK installed.
Comment 2 Daniel Richard G. 2007-06-08 06:12:38 UTC
Created attachment 89587 [details] [review]
Patch v1.1 against current SVN

Whoops---forgot to include a file in the patch.

app/core/Makefile.am:

* Added a rule to generate gimp-core-pixbufs.h when needed. I put in .$(OBJEXT) and .lo forms just for completeness (only the first one is needed). Stuffed the obnoxiously long file path into a variable for brevity.
Comment 3 Sven Neumann 2007-06-08 09:41:45 UTC
I don't see any point in doing this. You don't need make dist, you are not doing releases. And doing such changes now only bears the risk of breaking things. Also we can't update to a more recent version of intltool until it is fixed (see bug #436241).

I am somewhat tempted to close this report as WONTFIX but I might look at the patch and see if it contains anything useful.
Comment 4 Sven Neumann 2007-06-08 11:15:37 UTC
2007-06-08  Sven Neumann  <sven@gimp.org>

	Applied parts of a patch from Daniel Richard G. (bug #445374):

	* themes/Default/images/Makefile.am
	* data/tips/Makefile.am
	* menus/Makefile.am: more srcdir/builddir tweaks.

The other changes look like hacks with the sole purpose of getting something to work that is not worth supporting. Closing this report as WONTFIX.
Comment 5 Daniel Richard G. 2007-06-08 13:42:37 UTC
Some of the changes are hackish, but that's just working with what's there. Currently, you have a broken dependency tree; you have to do a full build before "make dist". I'd like to see the gimp-console bit handled in a better way, but that's going to be a much bigger patch that shouldn't come from me.

(As much as I say that having "make dist" work from a clean tree would be nice, it's really something that should be possible in the first place. Only the GIMP Team does official releases, but the GPL means that anyone can make a "release.")

Sven, how about leaving this bug open, targetting 2.5/2.6? Especially if intltool is holding things up, it'll have to simmer for a while. I'd like to see a better approach come together on this.
Comment 6 Sven Neumann 2007-06-08 18:57:00 UTC
Anyone can make a release. Our tree passes 'make distcheck' just fine and 'make distcheck' make sure that you can do a release from the released tarball.

Having to run before 'make' before you can 'make dist' is not a problem. There's no point in keeping a bug report for it open. We have enough other things to worry about.