https://bugs.kde.org/show_bug.cgi?id=406177
Bug ID: 406177
Summary: Poor relocatability making snap building a pain
Product: frameworks-kdoctools
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: kde-doc-engl...@kde.org
Reporter: sit...@kde.org
CC: kdelibs-b...@kde.org
Target Milestone: ---
For building snaps based on a content snap (similar to flatpak runtime), stuff
needs to be relocatable. For example everything gets configured to /usr but in
fact gets installed and run from /snap/foobar/usr/ (the /snap even could be
anything as far as I understand).
This is a bit problematic with kdoctools because it will hardcode asset paths
at build time.
- the replaceURLList in xslt.cpp is always going for DOCBOOK_XML_CURRDTD.
Ideally it should first try to locate the path via QStandardPaths and only fall
back to the hardcoded variant when QSP had no results. A similar approach is
already used in locateFilesInDtdResource().
- some of the customization files generate with @DOCBOOKXSL_DIR@. Ideally I
think DOCBOOKXSL_DIR should be calculated relative to the CMAKE_INSTALL_PREFIX
(i.e. be ../../docbook-xsl/ or something like that). So the ultimate runtime
paths do not matter so long as the docbook assets are in the correct relative
location. Alternatively I suppose one could run the xsl's through configuration
at runtime to, again, either use a QSP'd or hardcoded path as applicable. I
expect that would be vastly more work than simply making the DIR var relative
OBSERVED RESULT
kf5.kdoctools: Error: `xmllint --noout` outputted text
file:/snap/kde-frameworks-5-core18-sdk/current/usr/share/kf5/kdoctools/customization/dtd/kdedbx45.dtd:101:
warning: failed to load external entity
"file:/usr/share/xml/docbook/schema/dtd/4.5/docbookx.dtd"
EXPECTED RESULT
Applications building properly by locating assets relative to where meinproc is
at runtime.
--
You are receiving this mail because:
You are watching all bug changes.
