DocBook XML & XSL: new dependencies

[Luigi Toscano]

Alexander Neundorf wrote:
> On Friday 07 May 2010, Luigi Toscano wrote:
>> Alexander Neundorf wrote:
>>> On Thursday 06 May 2010, Luigi Toscano wrote:
>>>> Alexander Neundorf wrote:
>>>>    >
>>>>    >   Are the two find-modules supposed to be installed ?
>>>>    >   IOW, are docbookxml and docbook xsl only required when building
>>>>    >  kdelibs or for all other KDE modules too ?
>>>>
>>>> They are required whenever you need to compile documentation, but the
>>>> path
>>>
>>> This means they are required for every KDE module ?
>>
>> No: the path to the XML DTD and to XSL stylesheet will be hardcoded in some
>> files (meinproc executable, kdex.dtd). Other KDE modules/programs won't
>> need to use FindDocBookX* just to generate the documentation.
>
> If the two files will not be installed, then all the rest is not so critical,
> because then they are only internal modules, i.e. not part of our public
> interface.
Ok, I see :)


>>>> to the DTDs/XMLT will be discovered and hardcoded (like now), so
>>>> exporting them shouldn't be needed.
>>>
>>> I don't understand completely ?
>>> What will be hardcoded and where ? And what do you mean with exporting ?
>>
>> Installing as part of the public API. Is there another way for other
>> modules to use the variables defined by one of these two cmake modules? Like
>> those ones:
>>>> But there are two possible consumer for them: -
>>>> the xmlcheck plugin for kate (kdesdk) which needs to be touched anyway
>>>> because refers to the internal copy of XML DTDs, and
>>>> - the docbook exporter for umbrello, which does the same for xslt.
>
> These two need the information at runtime, not at build time, right ?
Right now the paths is hardcoded, but from the logical point of view they 
needs those informations as run-time dependencies, yes.

> So this would be a runtime dependency, not a build dependency.
> If the path is hardcoded into meinproc, maybe a switch to meinproc could be
> added to print just this path and exit ?
>
> Another option would be to put the path into the KDELibsDependencies.cmake
> file as an additional variable, like KDE4_DOCBOOK_STUFF_DIR (but with a
> proper name), then it can be used at build time by all other KDE modules.
Two variables are needed. Apart from that, either way, I don't have a strong 
opinion about which would be the better way (Albert?).
Must it be decided before the freeze?

> FindDocBookXML.cmake:
> the part where you set DOCBOOKXML_CURRENTDTD_DIR manually shouldn't be
> necessary, this is already done by the find_package_handle_standard_args()
> below.
Fixed.

>
> Must the version be fixed to 4.2 or do other versions work too ?
No, this depends on the specific version of DTD used by DocBook documents. It 
could happen that we will migrate to a newer version in the KDE SC 4.x 
timeframe (though at this moment I wouldn't bet on this :) and in that case we 
would use *_OLDDTD_*)
I fixed the script to store that value.

>
> FindDocBookXSL.cmake:
> As above, the part where you set DOCBOOKXSL_DIR manually can be removed.
Fixed.

Thanks for the review!
Can I commit them now (and put the needed code into kdoctools to activate them)?

Ciao
-- 
Luigi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FindDocBookXML.cmake
Type: text/x-cmake
Size: 1956 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20100509/8e6ca4a6/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FindDocBookXSL.cmake
Type: text/x-cmake
Size: 862 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20100509/8e6ca4a6/attachment-0001.bin