[OS X] "unknown type name 'KARCHIVE_DEPRECATED'" building kdoctools

[René J. V. Bertin]

David Faure wrote:

> But this would have:
> - made the porting effort to KF5 even greater, for all the existing code

I'm tempted to say that the effort of adding a path component in front of 
headers is rather small compared to all the other stuff that blew up in the 
transition, with potentially considerable benefits:
- shorter and thus easier to read compilation commands (less -I/-isystem 
arguments)
- much less potential clashes because you can only add to the header search path

Cf py2 vs py3: this would have been the sort of thing that an automatic parser 
could have corrected.

> - made it impossible to move classes between frameworks

Less practical, you mean?

> These are the reasons why Qt decided on <QLineEdit> and we decided on
> <KLineEdit>.

Forgive me if I don't take "Qt" as a reference for doing nothing the easy way 
that favours dev laziness over clean coding...

> Get your kdelibs4 headers out of the way and everything will be fine :)

I've been working on that, but just the headers. It seems that all it takes is 
building kdelibs4 with -DINCLUDE_INSTALL_PATH=/opt/local/include/KDE4 (after 
checking there's no current use of /opt/local/include/kde4 which would lead to 
other issues). Afterwards one can simply rebuild offending KDE4 packages as they 
declare themselves, to move their headers out of the way too.
It's a bit surprising this isn't documented somewhere, not even nicely visible 
in the kdelibs4 toplevel CMake file....

R.