Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 404495 - dev-util/gtk-doc: automagic build-time detection of pdf generator
Summary: dev-util/gtk-doc: automagic build-time detection of pdf generator
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Gentoo Linux Gnome Desktop Team
Depends on: 129368
  Show dependency tree
Reported: 2012-02-19 09:14 UTC by Martin von Gagern
Modified: 2020-10-10 17:29 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

Drop build-time magic (gtk-doc-1.18-no-automagic-pdfgen.patch,1.14 KB, patch)
2012-03-07 14:11 UTC, Martin von Gagern
Details | Diff
Ebuild modifications (gentoo404495b.patch,642 bytes, patch)
2012-03-07 14:13 UTC, Martin von Gagern
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin von Gagern 2012-02-19 09:14:19 UTC
The configure script for gtk-doc will autodetect what binary to use to convert XML to PDF. It prefers dblatex but falls back to fop. Not sure if dblatex as installed by dev-tex/tex4ht is usable, as that isn't on the path normally. I guess we'd need a new ebuild for to support that. fop is provided by dev-java/fop on Gentoo, but won't be usable either as using that requires a file gtk-doc-fo.xsl which the build system doesn't install automatically.

The really ugly part, though, is this: the autodetection is performed at compile-time, and the absolute path to the corresponding binary is hardcoded into the gtkdoc-mkpdf script. The dependencies in the ebuild do not mention any of these. As a consequence

- some systems might build PDF successfully, others might fail trying, and yet others might not even try, all of this depending on the set of packages available at build-time.

- binaries available at build-time might be missing at run-time, as the ebuild doesn't depend on them.

All of this is ugly and against Gentoo style. So I suggest you either discuss improvements with upstream, or tweak the build process so that you can control the pdf generation mechanism independent from the set of installed binaries. You could add use flags (e.g. "dblatex" and "fop") to control which backend should be used for pdf generation. The script should follow that choice, as should the dependencies. And in the case of fop, the missing xsl file should be made available as well.
Comment 1 Martin von Gagern 2012-02-19 09:33:41 UTC
See bug #403165 for problems related to this issue, observed in the wild.
Comment 2 Martin von Gagern 2012-03-07 14:11:45 UTC
Created attachment 304541 [details, diff]
Drop build-time magic

This patch to will simply pretend that dblatex and fop could not be found. It thereby drops the build-time magic, thus avoiding a factual dependency on a dblatex binary as well as the problems caused by the missing xslt file for fop.

A future solution to this problem might be more elaborate:
- The ebuild could offer USE flags to select a PDF generator, passing that choice to configure via AC_WITH directives which have to be patched in as well.
- The gtkdoc-mkpdf script could select a suitable generator at runtime.
Both of these require work, and might be better addressed upstream. So this patch here is a bare-bones solution: fix the core problem, and nothing more.
Comment 3 Martin von Gagern 2012-03-07 14:13:53 UTC
Created attachment 304543 [details, diff]
Ebuild modifications

These are the ebuild modifications required to apply the patch and recreate the configure script. Nothing special, but attached for the sake of completeness.
Comment 4 Martin von Gagern 2012-03-07 16:02:31 UTC
(In reply to comment #3)
> Ebuild modifications in attachment 304543 [details, diff]

Those are less than perfect: they cause the repeated execution of elibtoolize, which in turn causes warnings to be reported to the user, asking for a bug report. It looks to me as if both eautoreconf and gnome2_src_prepare would call elibtoolize unconditionally, so I see no easy way to avoid this. If this is in fact correct, a change to the eclasses to allow such scenarios would be nice.
Comment 5 Alexandre Rostovtsev (RETIRED) gentoo-dev 2012-03-08 06:39:10 UTC
Thank you for your analysis.

Apparently, gtk-doc upstream feel that fop is unreliable enough that they comment it out by default. Bug #403165 is not caused by gtk-doc running fop, but by gtk-doc running xsltproc to prepare input for a fop run that never happens. In other words, autodetected fop in gtk-doc only causes build failures and serves no useful purpose whatsoever.

I have therefore simply hard-disabled fop in gtkdoc-mkpdf in gtk-doc-1.18-r1, which should at least eliminate the build failures.

However, the full solution is to use dblatex and depend on it via a USE flag (e.g. USE=pdf). For this, we first need dblatex in portage.