DocBook XML & XSL: new dependencies

Albert Astals Cid aacid at kde.org
Mon May 10 17:44:43 CEST 2010


A Diumenge, 9 de maig de 2010, Luigi Toscano va escriure:
> 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?

Doing what Alex suggests (meinproc printing and exiting) kind of makes sense 
to me since it follows what we already do with some other apps.

Albert


More information about the Kde-buildsystem mailing list