Making KDocTools independent of KArchive

[Alexander Neundorf]

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