On Wednesday 25 September 2013, Albert Astals Cid wrote: > El Dimarts, 24 de setembre de 2013, a les 14:09:57, Kevin Ottens va escriure: > > On Tuesday 24 September 2013 13:48:55 Albert Astals Cid wrote: > > > El Dimarts, 24 de setembre de 2013, a les 08:49:20, Kevin Ottens va > > > > escriure: > > > > On Monday 23 September 2013 13:09:05 Nicolás Alvarez wrote: > > > > > Maybe we can use a third-party docbook-to-manpage conversion tool. > > > > > On Linux > > > > > it would be easy to install, and on Windows it wouldn't be needed > > > > > ("what's > > > > > a manpage?"). And still leave it optional everywhere... > > > > > > > > Thats a very good question. Maybe in that case kdoctools is indeed > > > > overkill. Someone would have to investigate if something else could > > > > be used though. > > > > > > That's really weird, we have a solution that works, and you want to use > > > something else? > > > > > > What does that gives us? > > > > > > That stuff in kde now depends in two docbook-to-manpage conversion > > > tools instead of one? > > > > > > Are you sure that's an improvement? > > > > Well, as highlighted we have a dependency issue there, so it's either: > > 1) no docbook in tier 1 and tier 2 frameworks; > > 2) we use a different docbook to manpage tool for tier 1 and tier 2 > > > > frameworks. > > Why you guys don't treat e-c-m as a dependency for the tier system but > treat kdoctools as one? > > I mean they are both prerequisites for the other modules (and if you remove > KArchive from kdoctools as the thread title suggests both are 'non-kde'), > aren't they?
Is kdoctools only a buildtime dependency or also a runtime dependency, i.e. is it a library which is linked against ? e-c-m is only needed at compile time. Alex _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel