DocBook XML & XSL: new dependencies

[Alexander Neundorf]

On Wednesday 26 May 2010, Luigi Toscano wrote:
> 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.

Sounds good :-)

> >>> 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.

Ah, ok.

> >> 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...? :)

Hmm, not sure ;-)

> >>> 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.

In order to use these variables in the same directory where the 
find_package(DocBookXslt/XML) is used they don't have to be cache variables, 
normal variables will do.
If it is a cache variable, I would suggest to change its type from "INTERNAL" 
(which could also be named "HIDDEN") to STRING and mark it as advanced (using 
mark_as_advanced()).
This way it is available in the cache editor (cmake-gui), but only when 
advanced variables are enabled.

Alex