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 578765 - no rule to make manpages
no rule to make manpages
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Documentation
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2009-04-12 14:45 UTC by Frederic Peters
Modified: 2011-01-04 16:12 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Don't try to install manpages if not building them (1.67 KB, patch)
2009-04-14 20:42 UTC, James Andrewartha 		rejected Details | Review

Description Frederic Peters 2009-04-12 14:45:09 UTC 
33857adc7dbf01f056a9c38d639194a4f4ba1498 removed the generated manpages, however --enable-man is still off by default, users (and buildbots) will thus experience this error:

make[3]: Leaving directory `.../checkout/gnome2/gtk+/docs/reference'
No rule to make target `gdk-pixbuf-csource.1', needed by `all-am'.  Stop.

See <http://build.gnome.org/builders/gtk%2B-RHEL5/builds/543/steps/gtk%2B%20build/logs/stdio> for example.
Comment 1 Matthias Clasen 2009-04-12 18:19:03 UTC 
> however --enable-man is still off by default, users (and buildbots) will thus
> experience this error:

Just turn it on then ?! 
Users who build from git are expected to be able to handle these minor hiccups...
Comment 2 James Andrewartha 2009-04-14 20:42:55 UTC 
Created attachment 132657 [details] [review]
Don't try to install manpages if not building them

This patch fixes the build when not using --enable-man.
Comment 3 Behdad Esfahbod 2009-04-14 20:45:28 UTC 
Comment on attachment 132657 [details] [review]
Don't try to install manpages if not building them

This is wrong.  When users are building Gtk+ tarballs, we don't expect they enabling man page generation but we still want to install the bundled manpages.
Comment 4 Behdad Esfahbod 2009-04-14 20:47:22 UTC 
Matthias, perhaps you can copy from Pango.  See pango/docs/Makefile.am

In short, if man rebuilding is not enabled, it creates a dummy manpage file.  It also adds a dist hook to make sure such dummy man pages don't make it into a tarball.

Here's the relevant bit:

man_MANS = pango-querymodules.1
if ENABLE_MAN
.xml.1:
        @XSLTPROC@ -nonet http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl $<
dist-local-check-mans-enabled:
        @if grep "Man generation disabled" $(man_MANS) >/dev/null; then $(RM) $(man_MANS); fi
else
$(man_MANS):
        @echo Man generation disabled.  Creating dummy $@.  Configure with --enable-man to enable it.
        @echo Man generation disabled.  Remove this file, configure with --enable-man, and rebuild Pango > $@
dist-local-check-mans-enabled:
        @echo "*** --enable-man must be used in order to make dist"
        @false
endif
Comment 5 Daniel Macks 2009-06-01 21:31:15 UTC 
Looks like the patch from Comment #3 got applied to 2.16 branch and released in 2.16.2 (commit 663bf3db0efde02f96e34bc08846356be3240f7f by Stefan Kost, according to the 2.16.2 ChangeLog) without this bug getting touched. Wonder if Stefan didn't see this bug-report and followup discussion? Anyway, now I'm getting the user-visible breakage noted in Comment #3 whereas 2.16.1 worked fine.
Comment 6 Sebastien Bacher 2009-06-02 16:41:22 UTC 
the git change breaks manpage installation for distribution for example, the current 2.17 tarball is buggy too
Comment 7 Matthias Clasen 2011-01-04 16:12:33 UTC 
We do what behdad proposed in commen #4, now.