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.
The windows-specific code paths of the cmake files have some (twisted, but reported to be working) logic to support relocation.
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
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.