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 794571 - Out of tree builds cause make install to re-gen gtk-doc
Out of tree builds cause make install to re-gen gtk-doc
Status: RESOLVED OBSOLETE
Product: gtk-doc
Classification: Platform
Component: general
1.27
Other Mac OS
: Normal normal
: ---
Assigned To: gtk-doc maintainers
gtk-doc maintainers
Depends on:
Blocks:
 
 
Reported: 2018-03-21 16:46 UTC by Ross Burton
Modified: 2018-05-22 13:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Ross Burton 2018-03-21 16:46:28 UTC 
If glib is configured to do an out-of-tree build then this happens:

1) configure runs and generates build/docs/reference/glib/version.xml
2) make all runs, the gtk-doc.make setup-build target copies all content files from $srcdir to $builddir.  This replaces the generated version.xml with the original in the tarball.  It then proceeds to generate gtk-doc.
3) make install runs, make notices that version.xml is older than config.status, so re-runs config.status to regenerate version.xml and so regenerates the gtk-doc again before installing it.

My hacky patch is:
--- a/gtk-doc.make
+++ b/gtk-doc.make
@@ -113,3 +113,3 @@ setup-build.stamp:
 	      test -f $(abs_srcdir)/$$file && \
-	        cp -pf $(abs_srcdir)/$$file $(abs_builddir)/$$file || true; \
+	        cp -pn $(abs_srcdir)/$$file $(abs_builddir)/$$file || true; \
 	    done; \


(only copy files which don't exist already)

But why does gtk-doc need to copy the content at all?
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2018-03-23 21:19:54 UTC 
In this scenario I wonder if configure should actually generate a version.xml if it is already in the tarball?

The real fix is to review all the tools to handle srcdir != builddir. Basically we need to pass a both dirs to each gtkdoc tool and make sure files are looked for in both locations. So one step would be to just turn this off and see what fails. I am trying to release a new version right now and won't have time for this unfortunately.
Comment 2 Stefan Sauer (gstreamer, gtkdoc dev) 2018-03-24 14:27:42 UTC 
Ross, did you try -u instead of -n?
  -n, --no-clobber             do not overwrite an existing file (overrides
                                 a previous -i option)
  -u, --update                 copy only when the SOURCE file is newer
                                 than the destination file or when the
                                 destination file is missing
Comment 3 Ross Burton 2018-03-26 12:35:14 UTC 
--update also fixes the problem and I agree is probably a better fix.
Comment 4 GNOME Infrastructure Team 2018-05-22 13:14:01 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk-doc/issues/43.