Forward includes

[Aleix Pol]

On Tue, Oct 22, 2013 at 11:06 AM, Ivan Čukić <ivan.cukic at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20131023/999770f9/attachment.html>