GNOME Bugzilla – Bug 466963
1.8 makes make distcheck fail
Last modified: 2007-09-10 21:02:30 UTC
On some gnome modules that doesn't include gtk-doc.make as part of their version controlled files, gtk-doc 1.8 gtk-doc.make makes make distcheck fail. For example, libglade fails unless I copy the gtk-doc.make from libgnomeprint. The one in libgnomeprint is an old version with "*** gtk doc ..." but I don't know precisely the version. The same kind of failure can be seen on glib and probably a lot of other modules listed in http://live.gnome.org/GnomeGoals/DistCheck The error looks like: gtk-doc: Linking scanner libtool: link: cannot find the library `../glade/libglade-2.0.la' or unhandled argument `../glade/libglade-2.0.la' Linking of scanner failed: make[1]: *** [scan-build.stamp] Erreur 1 make[1]: quittant le répertoire « /home/eva/devel/gnome-svn/libglade/doc » make: *** [distdir] Erreur 1 This is because libglade-2.0.la in this case is not built before gtk-doc call. I suppose this is some makefile problem but I couldn't find something obvious yet.
I don't think its gtk-docs fault. Could you attach the Makefile.am and the modified/old gtk-doc.make to this report?
Created attachment 93757 [details] libglade-HEAD-Makefile.am this is the current Makefile.am I'm working with. It only has little modifications wrt to the svn version (use of autofoo variables copied from libgnomeprint example) but it doesn't make a difference actually. It's taken from the revision 537 of trunk of libglade
Created attachment 93758 [details] gtk-doc.make this file is the gtk-doc.make from the 1.8 version packaged on gentoo.
Created attachment 93759 [details] libgnomeprint's gtk-doc.make this is the gtk-doc.make from libgnomeprint as it can be checkout from trunk revision 2261
A note first, gtk-doc has always broken distcheck and it has only seemed to pass thanks to terrible cheating. There is no way to build with srcdir actually being read-only. This should change with 1.9, the goal is not passing distcheck but getting things right so that it will pass distcheck naturally. But the dependencies are really wrong. Since the compilation of the object scanner is hidden in a perl script, make cannot know it needs the library built first to link the scanner with it. But this has been always so, I don't understand how 1.8 could be different. (And it is also quite hard to hit, I build with -j4 or higher and have never encountered it.) Quite the contrary, gtk-doc 1.8 gtk-doc.make runs scangobj *later*, so if anything, it should make this problem harder to hit. Therefore I wonder whether this is really the cause. How to reproduce the problem? Do you use parallel builds? Fetching libglade and running make distcheck (with -j4) does not do it for me. If it really is the problem (and then someone explain to me why it is observer with 1.8 only) the proper solution is to make the scan target depend on the libraries the object scanner links with. This cannot be done compatibly (i.e. people will have to set a new variable in the Makefile.am to enable it) -- unless one assumes GTKDOC_LIBS contains only libraries (and not for instance linker flags).
I don't use parallel make to build from svn generally and I can reproduce this problem 100%. I'll looks into adding a variable to the Makefile.am that would solve this issue. Btw, hidding objects of the scanner in a perl script is due to what ? can't it somehow be in the form of real makefile rules in gtk-doc.make ?
(In reply to comment #6) > I don't use parallel make to build from svn generally and I can reproduce this > problem 100%. I'll looks into adding a variable to the Makefile.am that would > solve this issue. Well, I cannot. $ svn co http://svn.gnome.org/svn/libgnomeprint/trunk libgnomeprint $ cd libgnomeprint $ ./autogen.sh --enable-maintainer-mode $ make distcheck ... ===================================================== libgnomeprint-2.18.0.tar.gz is ready for distribution ===================================================== $ gtkdoc-scangobj --version 1.8 Moreover, if you do not use parallel builds, you cannot observe the problem I mentioned at all, the reason must be different. I am also confused about `gnome modules that doesn't include gtk-doc.make as part of their version controlled files' because libgnomeprint *does* include its own copy in svn: $ svn info gtk-doc.make Path: gtk-doc.make Name: gtk-doc.make URL: http://svn.gnome.org/svn/libgnomeprint/trunk/gtk-doc.make Repository Root: http://svn.gnome.org/svn/libgnomeprint Repository UUID: 552ab3f7-e625-0410-a336-e971776fdb53 Revision: 2261 Node Kind: file Schedule: normal Last Changed Author: jody Last Changed Rev: 1559 Last Changed Date: 2003-08-12 17:36:09 +0200 (Tue, 12 Aug 2003) Text Last Updated: 2007-08-16 09:54:33 +0200 (Thu, 16 Aug 2007) Properties Last Updated: 2007-08-16 09:54:29 +0200 (Thu, 16 Aug 2007) Checksum: 2efa5a621751b7c0cf75fc72c6487ce1 > Btw, hidding objects of the scanner in a perl script is due to what ? can't it > somehow be in the form of real makefile rules in gtk-doc.make ? Probably due to Damon originally writing it this way... The script creates the C source code and builds it and runs it and deletes it again. Perhaps it can be created using real make rules, even though you will get an optional built source file with complex dependencies -- which traditionally is a good method to expose automake bugs -- and by optional I mean that we might not know whether to build it or not until gtkdoc-scan is run, which is something that maybe even cannot be expressed reasonably in the Makefile.
> Well, I cannot. > > $ svn co http://svn.gnome.org/svn/libgnomeprint/trunk libgnomeprint > $ cd libgnomeprint > $ ./autogen.sh --enable-maintainer-mode > $ make distcheck > ... > ===================================================== > libgnomeprint-2.18.0.tar.gz is ready for distribution > ===================================================== > > $ gtkdoc-scangobj --version > 1.8 > > Moreover, if you do not use parallel builds, you cannot observe the problem I > mentioned at all, the reason must be different. > > I am also confused about `gnome modules that doesn't include gtk-doc.make as > part of their version controlled files' because libgnomeprint *does* include > its own copy in svn: I mean that libgnomeprint provides gtk-doc.make in its repository while glib, libbonobo, libglade don't and those fail distcheck all with the same error: libbonobo example: ./autogen.sh make distcheck [snip] gtk-doc: Compiling scanner gcc -g -O2 -g -O2 -DGNOMELOCALEDIR=/usr/local/share/locale -DORBIT2=1 -pthread -I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I../.. -I../.. -c libbonobo-scan.c -fPIC -DPIC -o .libs/libbonobo-scan.o gcc -g -O2 -g -O2 -DGNOMELOCALEDIR=/usr/local/share/locale -DORBIT2=1 -pthread -I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I../.. -I../.. -c libbonobo-scan.c -o libbonobo-scan.o >/dev/null 2>&1 gtk-doc: Linking scanner libtool: link: cannot find the library `../../bonobo/libbonobo-2.la' or unhandled argument `../../bonobo/libbonobo-2.la' Linking of scanner failed: make[2]: *** [scan-build.stamp] Error 1 > > Btw, hidding objects of the scanner in a perl script is due to what ? can't it > > somehow be in the form of real makefile rules in gtk-doc.make ? > > Probably due to Damon originally writing it this way... The script creates the > C source code and builds it and runs it and deletes it again. > > Perhaps it can be created using real make rules, even though you will get an > optional built source file with complex dependencies -- which traditionally is > a good method to expose automake bugs -- and by optional I mean that we might > not know whether to build it or not until gtkdoc-scan is run, which is > something that maybe even cannot be expressed reasonably in the Makefile. > I see. Also I'm not sure this is as hard as it might seem to fix (but maybe I'm too optimist :)). I'll try with a checkout of gtk-doc repository when I have time.
(In reply to comment #8) > I mean that libgnomeprint provides gtk-doc.make in its repository while glib, > libbonobo, libglade don't and those fail distcheck all with the same error: I see, the problem is not in gtk-doc 1.8 gtk-doc.make then because both packages using it and using their own version behave the same. At least something is clear. > libbonobo example: > ./autogen.sh > make distcheck > [snip] What is [snip]? I can see the failure, but I cannot see what happened before it. Please attach the output of all the commands above with &>logfile.
Created attachment 93893 [details] logfile.txt required logfile.
I see and can even reproduce now (I probably inadvertently also run make when I tried to reproduce it -- and no cleaning really got the tree into the original state). Making dists directly from a SVN checkout this way could never work. Since make does not know how to create ../../bonobo/libbonobo-2.la when it gets into doc/api/ and finds it does not exist, adding $(GTKDOC_LIBS) into scan-build.stamp dependencies would only produce a different error (see paper `Recursive make considered harmful'). So a) Do not do it then. After a fresh checkout, bootstrap and build the project before making dists. This is IMO a reasonable requirement for bootstrapping. b) If a) is not acceptable for political reasons, add dist: all to the top-level Makefile.am. In this case be warned that unpacking the source tarball and running `make dist' will also build the package first, which is something quite undesirable. c) If b) is not acceptable because entirely unpractical, invent some complex workaround for recursive make to get it the dependencies right both for checkouts and for tarballs. Suggestion how to facilitate this in gtk-doc are welcome (well, it depends on how crazy they will be) but it is a global problem not solvable in gtk-doc makefiles alone. It simply needs the project built completely once to bootstrap. d) Do not distribute generated files (HTML documentation). Technically this is the only clean solution, unfortunately it is not an option in practice.
@Stefan, could you comment on why this is NOTABUG ? I personally feel that braking make distcheck (on a clean checkout to be really precise) is really bad behavior even if I understand that the current implementation of gtk-doc doesn't allow to workaround that.
I'm not Stefan, but I will comment. NOTABUG means it's a design decision of some kind. The design decision here is to distribute HTML documentation -- which is only possible after building the project completely. Everything else follows from that. As I noted, it might not be completely impossible to do c). But projects do not seem to have the Makefile trickery in place. If they have and there is something *particular* gtk-doc should do, feel free to request it. (Actually, I'm surprised making dists directly from a svn checkout is perceived as normal -- I have typically lots of files that require full project build to generate for the first time.)
(In reply to comment #13) > I'm not Stefan, but I will comment. > > NOTABUG means it's a design decision of some kind. The design decision here is > to distribute HTML documentation -- which is only possible after building the > project completely. Everything else follows from that. yes, I perfectly agree here > As I noted, it might not be completely impossible to do c). But projects do > not seem to have the Makefile trickery in place. If they have and there is > something *particular* gtk-doc should do, feel free to request it. I'll try to look into this bug I don't have much free time :) > (Actually, I'm surprised making dists directly from a svn checkout is perceived > as normal -- I have typically lots of files that require full project build to > generate for the first time.) the rationale is that doing distcheck will result in one compilation in any case so the documentation generation would succeed inside the environment of the distcheck while it can't on a clean checkout for reason that were exposed previously. I perfectly understand the reason leading to this problem but this explanation leads me to think it's a bug. What do you think ?
(In reply to comment #14) > the rationale is that doing distcheck will result in one compilation in any > case so the documentation generation would succeed inside the environment of > the distcheck while it can't on a clean checkout for reason that were exposed > previously. I perfectly understand the reason leading to this problem but this > explanation leads me to think it's a bug. What do you think ? If you just check out from svn, run autogen and make distcheck, then distcheck entirely correctly fails, because your base tree is *not* ready for distribution, no matter what could happen inside the test build tree. The answer (IMO conceptually correct) is distcheck: all except that 1) I'm not sure know how to get it there (portably -- automake does not seem to provide a pre-distcheck hook) 2) It has nothing to do with gtk-doc, you have to fix project makefiles.