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