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