DocBook XML & XSL: new dependencies

Luigi Toscano luigi.toscano at tiscali.it
Wed May 26 23:47:23 CEST 2010


Alexander Neundorf wrote:
> On Wednesday 26 May 2010, Luigi Toscano wrote:
>> Alexander Neundorf wrote:
>>> On Wednesday 26 May 2010, Luigi Toscano wrote:
>>>> Alexander Neundorf wrote:
>>>>> Ok, stupid question.
>>>>> Now I actually tried to build kdelibs again, and it failed because the
>>>>> docbook stuff wasn't found.
>>>>> The given link in the error message is
>>>>> http://docbook.org/schemas/4x.html So, what should I download from
>>>>> there ?
>>>>
>>>> It's not so easy from that link, I changed the URL to something more
>>>> useful.
>>>
>>> Ok.
>>>
>>> About FindDocBookXSL.cmake:
>>> it looks a bit unspecific to me to search for a file named "VERSION". Can
>>> we search for another, more specific file ?
>>> Maybe lib/lib.xsl ?
>>
>> You should blame upstream for this :)
>> VERSION, despite its name, it's an xml file.
>
> Ah, ok.
> Still, also other packages have files named "VERSION":
>
> [...]
> So a more unique filename would be good, one of the files which are always
> part of docbookxsl.
You are right; lib/lib.xsl seems to be the best choice.

>
>>> About FindDocBookXML.cmake:
>>> Right now only version 4.2 works for KDE ?
>>> Is there a reason why the variables have this "CURRENT" part in their
>>> name ?
>>
>> Because we *could* plan a migration to a newer version (i.e. 4.5), but in
>
> So 4.2 and 4.5 are not compatible ?
Our documentation is based on a custom "-//KDE//DTD DocBook XML V4.2-Based 
Variant V1.1//EN", which (as the definition suggests) is defined using DocBook 
XML v4.2. In case of a switch to a newer version, a new custom DTD should be 
defined and it will be based on another DTD. But during the transition phase 
we will need to support both. We could cut 4.1.2 now because almost all the 
documents have been converted long time ago.

>
>> this case we should probably keep the old version for older documents. Is
>> the advice concerning the versioned find_package still valid with this new
>> information?
>
> Finding two versions of the same package in one cmake tree is not really
> supported, e.g.
> find_package(Foo 1.0)
> find_package(Foo 2.0)
> does not work, both set the same variables, so they can hold only one version.
>
> You mean we would need to search for 4.2 and also for 4.5 ?
> Hmm, this will need some hacking.
>
> Or a FindDocBookXML.cmake and a FindDocBookXML45.cmake or something like this.
>
> You wanted to search for two versions in one file, once for CURRENT and once
> for OLD, right ?
> Hmm, possible, but also quite different what the usual cmake module does.
So the answer is...? :)


>
>>> Also, why do you put DOCBOOKXML_CURRENTDTD_VERSION in the cache ? And why
>>> as "INTERNAL" ?
>>
>> I put it in the cache to be able to use it later. INTERNAL because I'm
>> still a beginner with cmake and it seemed to me the right value.
>
> INTERNAL means you will not see it in the cache editor (cmake-gui and ccmake),
> so you are not able to change them (except using a plain text editor).
> What do you mean with "use it later" ?
I use it now in kdoctools/CMakeLists.txt to give more information, for example.

Regards
-- 
Luigi


More information about the Kde-buildsystem mailing list