Review Request 116670: Use absolute paths to refer to entities/elements defined in kdoctools

[Luigi Toscano]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116670/
-----------------------------------------------------------

(Updated March 12, 2014, 8:31 p.m.)


Status
------

This change has been marked as submitted.


Review request for KDE Frameworks, kdewin, Alexander Richardson, and Harald Fernengel.


Repository: kde4support


Description
-------

The processing of documentation still using DocBookXML 4.2, which depends on kde4support, currently fails on our Jenkins instance where each module has a different installation prefix with an error like:

---------------------------
Generating kate.1
file:///usr/share/xml/docbook/schema/dtd/4.2/dbpoolx.mod:215: warning: failed 
to load external entity "file:///srv/jenkins/install/linux/x86_64/g++/kf5-
qt5/frameworks/kde4support/inst/share/kdoctools5/customization/dtd/rdbpool.elements"
%rdbpool;
         ^
Entity: line 1: 
 %rdbpool; 
          ^
---------------------------
and similar for the other element/entity files referred. This does not happen in the "normal" installation because in that case those files will be found in the same directory ($prefix/share/kdoctools5/customization/dtd) and the relative path will work.

The attached patch change the paths in the compatibiliy DTD to be absolute path instead.

I have to question about this solution (kdewin group): will it work on windows? I guess so, as the directory returned by KDOCTOOLS_CUSTOMIZATION_DIR is set by KF5DocToolsConfig.cmake using KDOCTOOLS_DATA_INSTALL_DIR which uses PACKAGE_PREFIX_DIR, but I'm not totally sure.
Similar question for MacOSX.


Diffs
-----

  src/customization/dtd/kdex.dtd.cmake 1f75dd9 
  src/CMakeLists.txt d436846 

Diff: https://git.reviewboard.kde.org/r/116670/diff/


Testing
-------

It compiles, and a module whose documentation still uses the old DTD (oktate) compiles correctly.


Thanks,

Luigi Toscano

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-windows/attachments/20140312/82427f17/attachment.html>