Forward includes

[Ivan Čukić]

> The above is pretty much it on my side, but I'd like to add something:
> We should get those forwarding includes generated to not have to maintain

Lets bring this topic back from the dead.

I don't have a real preference between include/Module, include/KDE/Module and 
include/KF5/Module.

Main benefit of include/KF5/Module is the fact that the users will be able to 
have different non-ABI/API-compatible versions of KF installed at the same 
time, if this is needed at all.

As for pointing the cmake configs to that path, it might be tricky to achieve 
in all libraries. Namely those that rely on namespaces instead of prefixing 
the names of classes with K or KSomething.

For example, while #include<KJob> can work without collisions, it can not for 
libraries like Solid (classes named Camera, Video, Button -> needs to be 
#include<Solid/Camera> etc.) or KActivities (Controller, Info -> 
#include<KActivities/Info> etc.)

Cheers,
Ivan


-- 
The problem with object-oriented languages is they’ve got all this
implicit environment that they carry around with them. You wanted
a banana but what you got was a gorilla holding the banana.
  -- Joe Armstrong