DocBook XML & XSL: new dependencies

[Alexander Neundorf]

On Sunday 09 May 2010, you wrote:
> 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)?

Yes, go ahead.
But we'll have to do something on the version handling.

Alex