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
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel