On Tue, Oct 22, 2013 at 11:06 AM, Ivan Čukić <ivan.cu...@kde.org> wrote:
> > > 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 > I'll be sending a review soon, we can discuss it further over some code :). Aleix
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel