DocBook XML & XSL: new dependencies

Alexander Neundorf neundorf at kde.org
Sun May 9 18:31:33 CEST 2010


On Friday 07 May 2010, Luigi Toscano wrote:
> Alexander Neundorf wrote:
> > On Thursday 06 May 2010, Luigi Toscano wrote:
> >> Alexander Neundorf wrote:
> >>   >  On Tuesday 04 May 2010, Luigi Toscano wrote:
> >>   >>  as I announced on kde-core-devel[1], I'm working to remove the
> >>   >> embedded copies of XML and XSLT files from kdelibs/kdoctools. This
> >>   >> process will introduce two external dependencies; I'd like to
> >>   >> complete the migration before the release of 4.5, so the proposed
> >>   >> Find*.cmake modules for kdelibs
> >>   >
> >>   >  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.

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

> >>   >  Things which should be changed:
> >>   >  * use the find_package_handle_standard_args() macro for the status
> >>   >  output at the end and setting<package>_FOUND.
> >>
> >> Is it possible to specify a custom success message, other than the
> >> failure message?
> >
> > Currently not. What would you like to see ?
>
> I was thinking about a more complex message, but the first variable in the
> list is printed with the name of the dependency, so this point is not
> important.

Ok.

> > [...]
> > But when using find_package_handle_standard_args() this is not necessary
> > at all, it remembers what it has print the last time and only prints a
> > status message again if the output changes.
>
> Done.
>
> I applied the required changes, as you can see from the attachment.

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.

Must the version be fixed to 4.2 or do other versions work too ?

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

Alex




More information about the Kde-buildsystem mailing list