Bug 406177

Summary:	Poor relocatability making snap building a pain
Product:	[Frameworks and Libraries] frameworks-kdoctools	Reporter:	Harald Sitter <sitter>
Component:	general	Assignee:	Documentation Editorial Team <kde-doc-english>
Status:	REPORTED ---
Severity:	normal	CC:	kdelibs-bugs-null, luigi.toscano
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Harald Sitter 2019-04-03 10:56:38 UTC

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.

Comment 1 Luigi Toscano 2019-04-03 12:09:09 UTC

The windows-specific code paths of the cmake files have some (twisted, but reported to be working) logic to support relocation.

Comment 2 Luigi Toscano 2019-04-03 12:21:18 UTC

Note the this is not trivial because few files require a specific path. It may be relative and the problem could be solved for snaps, but it's not possible to use a dynamic path:
https://stackoverflow.com/questions/7939815/dynamically-include-other-xsl-files-in-xslt

See 
./src/customization/dtd/kdedbx45.dtd.cmake
./src/customization/kde-include-common.xsl.cmake
./src/customization/kde-include-man.xsl.cmake

Comment 3 Harald Sitter 2019-04-03 12:45:48 UTC

The biggest problem for me are paths that are compiled-in, the paths in the dtd/xsl files I can probably sed out for something more suitable at snap-buidtime. The binaries however are (currently) shared with regular deb builds, so it's far less trivial to get those bent into shape if they don't follow some environment variable.

I think relative paths would be fine for xsl/dtd and should work in all cases? What I was thinking about with runtime generation is to actually mimic what configure_file does currently, but at runtime.

e.g.
- install kde-include-man.xsl.tmpl
- at runtime meinproc figures out where the docbook-xml/docbook-xsl stuff lives, or fall back to compiled in paths
- open kde-include-man.xsl.tmpl
- QString.replace("@XSL_PATH@", determinedPath);
- write to $tmpdir/kde-include-man.xsl
- load the generated file with the now runtime-dependent includes

Granted I don't know much about how docbook works, so that may be a nonsensical idea.

If using relative paths would work, I think that'd be a sound solution that should work both for relocated trees as well as regular ones.