On Thu, Nov 14, 2013 at 5:04 PM, Aurélien Gâteau <agat...@kde.org> wrote:
> On 10.11.2013 18:27, Kevin Ottens wrote:
>
>> Hello,
>>
>> On Wednesday 06 November 2013 08:52:29 Aurélien Gâteau wrote:
>>
>>> Yesterday frameworks meeting spawned a discussion regarding folders
>>> in header files.
>>>
>>
>> I think there's an aspect missing in your proposal. There's the
>> convention we want for #include and where we install. That's in the
>> end two different things even though related.
>>
>> I think, that for all the frameworks, headers should be installed in:
>> $PREFIX/include/KF5/FrameworkName/
>>
>> FrameworkName would then contain both the regular .h headers and the
>> convenience camel case ones. If we go for that, we get something
>> consistent install wise and easy to deal with. Then the distinction
>> you make below is just about the include path we want when someone
>> pulls a framework in.
>>
>> I think the consensus is there should be two different situations:
>>>
>>> 1. 'k' prefixed header files
>>>
>>> If the header files of a framework are prefixed with a 'k', then
>>> headers should be installed in include and convenience headers should
>>> be installed in include/KDE.
>>>
>>
>> I think in a case like that we still want the includes installed in
>> $PREFIX/include/KF5/FrameworkName/ (convenience or not). But when
>> someone pulls the framework as a dependency then both
>> $PREFIX/include/KF5/ and $PREFIX/include/KF5/FrameworkName/ are added
>> in the include path, thus supporting the #include <kfoo.h> and
>> #include <KFoo> styles.
>>
>
> To support #include <kfoo.h> and #include <KFoo> you only need to have
> $PREFIX/include/KF5/FrameworkName/ in the include path. Adding
> $PREFIX/include/KF5/ would add support for
> #include <FrameworkName/kfoo.h> and #include <FrameworkName/KFoo>.
>
> Do we want to support this as well? (I have no strong opinion on this
> topic)
ecm_generate_headers will do it like that anyway
>
>
>
>> 2. Non-prefixed header files
>>>
>>> If the header files of a framework are not prefixed, then they should
>>> be installed in include/{lowercaseframework} and convenience headers
>>> should be installed in include/KDE/{CamelCaseFramework}.
>>>
>>
>> I think in a case like that we still want the includes installed in
>> $PREFIX/include/KF5/FrameworkName/ (convenience or not). But when
>> someone pulls the framework as a dependency then only
>> $PREFIX/include/KF5/ is added in the include path, thus supporting the
>> #include <FrameworkName/foo.h> and #include <FrameworkName/Foo>
>> styles.
>>
>> Some special files should still go in include:
>>>
>>> {lowercaseframework}_export.h {lowercaseframework}_version.h
>>>
>>
>> Make that $PREFIX/include/KF5/ instead of just include and I agree.
>>
>
> Wouldn't it be more self-contained to have those in
> $PREFIX/include/KF5/FrameworkName as well?
>
> After all, those includes are mostly internal, so they should not be the
> first files you meet if you wander in $PREFIX/include/KF5 IMO.
They should probably be in frameworkname/frameworkname_export.h. Usually we
have 2 folders for includes, the camel case for camel case includes and the
lowercase one with the actual includes.
>
>
> I think it departs quite a bit from your initial proposal, making it
>> slightly more complicated on the include path side, but it has pros
>> like:
>> * making it more homogeneous on the installation side;
>> * allows co-installability of major releases in the future.
>>
>> Opinions?
>>
>
> Works for me, just tell me your preference on the two points I
> mentionned above.
>
>
> Aurélien
>
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
Aleix
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
