Summary: | dev-util/gtk-doc: automagic build-time detection of pdf generator | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Martin von Gagern <Martin.vGagern> |
Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | CONFIRMED --- | ||
Severity: | enhancement | CC: | jstein, kripton |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 129368 | ||
Bug Blocks: | |||
Attachments: |
Drop build-time magic
Ebuild modifications |
Description
Martin von Gagern
2012-02-19 09:14:19 UTC
See bug #403165 for problems related to this issue, observed in the wild. Created attachment 304541 [details, diff]
Drop build-time magic
This patch to configure.ac 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.
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.
(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. 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. |