Making KDocTools independent of KArchive
Nicolás Alvarez
nicolas.alvarez at gmail.com
Mon Sep 23 16:01:25 UTC 2013
On Monday, September 23, 2013, Kevin Ottens wrote:
> On Saturday 21 September 2013 15:25:27 Albert Astals Cid wrote:
> > El Dissabte, 21 de setembre de 2013, a les 11:15:52, Stephen Kelly va
> >
> > escriure:
> > > Albert Astals Cid wrote:
> > > >> > Anyway as I was chatting with Aleix yesterday, kdoctools being a
> > > >> > tier1
> > > >> > framework "is not enough" since kconfig has docbook files (e.g.
> man
> > > >> > page of kconfig_compiler) so we need a tier0 here ;-)
> > > >>
> > > >> Where is kconfig now?
> > > >
> > > > Do I really need to do an ls for you?
> > >
> > > What I was trying to get at is that you seem to be implying that
> kconfig
> > > depends on kdoctools (ie, a tier1 depends on a tier2), therefore
> kdoctools
> > > can't be tier1. I don't follow that logic.
> >
> > Well, kconfig depends on kdoctools because as I said there is a docbook
> for
> > the kconfig_compiler manpage.
> >
> > So yes, there is a tier1 that depends on a tier2. That if as I
> understand we
> > plan to ship the kconfig_compiler manpage together with the kconfig
> > framework tarball.
>
> Well, I'm not sure we want to do that. This docbook seems useful only
> because
> kconfig_compiler --help does a poor job at documenting itself. So what
> about
> completing kconfig_compiler --help output to make it useful and get rid of
> the
> docbook?
>
> To me it looks like most of the docbook files in kdelibs are pretty much in
> the same situation and I'd favor proper --help support there than adding a
> dependency on kdoctool.
>
I assume making it an optional dependency (if not present, don't build the
manpage) doesn't help, because the current tiers fully allow having
kdoctools depend on kconfig, which would cause a circular dependency.
What does kdoctools buy us here? Maybe we can use a third-party docbook
--
Nicolás
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130923/8ede3bd0/attachment.html>
More information about the Kde-frameworks-devel
mailing list