GNOME Bugzilla – Bug 327499
devhelp install broken if builddir != srcdir
Last modified: 2013-03-18 15:12:55 UTC
The install-data-local target of the doc/devhelp Makefile does not use $srcdir to refer to the to-be-installed files. This breaks make install if srcdir and builddir are not the same. (This is in 2.6.23, but that is not yet in the Version list box, so I marked it as 2.6.22; I assume it is the same there)
Hum .... is that just for libxml2.devhelp ? I see install-data-local: $(mkinstalldirs) $(DESTDIR)$(DEVHELP_DIR) -@INSTALL@ -m 0644 libxml2.devhelp $(DESTDIR)$(DEVHELP_DIR) -@INSTALL@ -m 0644 $(EXTRA_FORMAT) $(DESTDIR)$(DEVHELP_DIR) -@INSTALL@ -m 0644 $(HTML_FILES) $(DESTDIR)$(DEVHELP_DIR) this should not break make install due to the leading -, at worse the files are not installed but make does not exit on an error. Now I could change the thrid line to -@INSTALL@ -m 0644 $(srcdir)/libxml2.devhelp $(DESTDIR)$(DEVHELP_DIR) But it looks like the other files would still generate an error. So explain fully or attach a patch describing precisely what is needed. Daniel
Created attachment 57581 [details] adjusted Makefile.am for doc/devhelp Well, when I said it breaks make install, I indeed only meant that the files don't get installed (to me, "make install" not installing what it's supposed to is breakage, even if the command exits with code 0). And no, it's not just libxml2.devhelp - at least in my Makefile, both $(HTML_FILES) and $(EXTRA_FORMAT) contain lists of files without $(srcdir)/ prefix. Attached is an adjusted Makefile.am; I also added $(srcdir)/ to the libxm2.devhelp rule itself, but that might not be needed (because of VPATH). Shouldn't do any harm either though.
reopening as requested information has been provided.
Uh... your Makefile builds $(srcdir)/libxml2.devhelp, which will also break in out-of-tree build situations, won't it? [in addition, a diff would be more readable]
Yes it does, but so does the original Makefile.am; my only changes were: - adding $(srcdir)/ to the contents (direct and indirect) of EXTRA_FORMAT and HTML_FILES - adding $(srcdir)/ to the installation command for libxml2.devhelp I agree that it would be better to rewrite more of the Makefile so that it works in situations with a read-only srcdir, but my immediate concern was with "make install" actually putting all relevant files in the install dir. Note: I see that in 2.8.0 (and perhaps also earlier releases), this has basically been applied, except that it uses things like $(EXTRA_FORMAT:%=$(srcdir)/%) to add a prefix. Is this sufficiently portable across "make" implementations?
Well, so far nobody has complained about it :-) Daniel
(In reply to comment #5) > Yes it does, but so does the original Makefile.am; my only changes were: With a diff, I would have known what was in the original Makefile and what was in your patch. :-)
so is this NOTABUG?
Not really, the problem may be here but, tim sent a ull new Makefile.am. The diffs he described are clearly not complete compared to current Makefile.am then he says that it might be fixed in 2.8.0 but I don't find what he suggests in the current git. I guess NEEDINFO is more appropriate than NOTABUG :-) Daniel
I downloaded the latest tarball at the time (2.8) and checked its Makefile.am; I thought I saw the $(EXTRA_FORMAT:%=$(srcdir)/%) stuff there. Now I don't see it, so not sure what I was looking at then. I went to https://git.gnome.org/browse/libxml2/tree/doc/devhelp/Makefile.am?id=v2.9.0 now to look at what seems to be the latest release tree. That doesn't have any $(srcdir) mentions (except when running xsltproc at the very end). However, after building from the 2.9.0 tarball, make -n -C doc/devhelp install shows the use of a for loop that takes each file either from the current dir or the corresponding srcdir. "make install" from the top works just fine. So it looks like this is handled right now (probably with some dependency on a version of autotools that handles things this way).
Ah thanks tim for closing the loop, so let's mark it as fixed :-) Daniel