Re: RFC Rules for installation of header files
Aurélien Gâteau wrote:
Looks like we have an agreement then. Let me recap:
# Installation dir
All header files are installed in $PREFIX/include/KF5/$Framework.
This includes 'k' prefixed headers like kfoo and KFoo,
non-prefixed headers such as bar.h and Bar, as well as special headers
such as ${framework}_export.h and ${framework}_version.h.
# Include path
For 'k' prefixed headers, include path is
$PREFIX/include/KF5/$Framework.
For non-prefixed headers, include path is $PREFIX/include/KF5.
Thanks for working on this!
Is the above agreed? It will require patching KDEInstallDirs.cmake in ecm.
Thanks,
Steve.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RFC Rules for installation of header files
On Thu, 14 Nov 2013 17:55:42 +0100, Kevin Ottens wrote:
On Thursday 14 November 2013 18:40:04 Aurélien Gâteau wrote:
Looks like we have an agreement then. Let me recap:
# Installation dir
All header files are installed in $PREFIX/include/KF5/$Framework.
This includes 'k' prefixed headers like kfoo and KFoo,
I assume you meant kfoo.h here.
non-prefixed headers such as bar.h and Bar, as well as special
headers
such as ${framework}_export.h and ${framework}_version.h.
# Include path
For 'k' prefixed headers, include path is
$PREFIX/include/KF5/$Framework.
For non-prefixed headers, include path is $PREFIX/include/KF5.
Is this correct?
Looks correct to me.
David pointed out on IRC this scheme would need a significant change
for
frameworks like KIO or Solid: includes to kio/foo.h would need to be
changed to KIO/foo.h, same with solid/* includes. Are you fine with
this?
Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RFC Rules for installation of header files
On Friday 15 November 2013 17:24:00 Aurélien Gâteau wrote:
On Thu, 14 Nov 2013 17:55:42 +0100, Kevin Ottens wrote:
On Thursday 14 November 2013 18:40:04 Aurélien Gâteau wrote:
Looks like we have an agreement then. Let me recap:
# Installation dir
All header files are installed in $PREFIX/include/KF5/$Framework.
This includes 'k' prefixed headers like kfoo and KFoo,
I assume you meant kfoo.h here.
non-prefixed headers such as bar.h and Bar, as well as special
headers
such as ${framework}_export.h and ${framework}_version.h.
# Include path
For 'k' prefixed headers, include path is
$PREFIX/include/KF5/$Framework.
For non-prefixed headers, include path is $PREFIX/include/KF5.
Is this correct?
Looks correct to me.
David pointed out on IRC this scheme would need a significant change
for
frameworks like KIO or Solid: includes to kio/foo.h would need to be
changed to KIO/foo.h, same with solid/* includes. Are you fine with
this?
I am, but that looks like a big breakage in source compatibility though. :-)
Probably stupid idea: What about having kde4support install the compatibility
headers for those?
Regards.
--
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RFC Rules for installation of header files
El viernes, 15 de noviembre de 2013, Kevin Ottens escribió:
On Friday 15 November 2013 17:24:00 Aurélien Gâteau wrote:
On Thu, 14 Nov 2013 17:55:42 +0100, Kevin Ottens wrote:
On Thursday 14 November 2013 18:40:04 Aurélien Gâteau wrote:
Looks like we have an agreement then. Let me recap:
# Installation dir
All header files are installed in $PREFIX/include/KF5/$Framework.
This includes 'k' prefixed headers like kfoo and KFoo,
I assume you meant kfoo.h here.
non-prefixed headers such as bar.h and Bar, as well as special
headers
such as ${framework}_export.h and ${framework}_version.h.
# Include path
For 'k' prefixed headers, include path is
$PREFIX/include/KF5/$Framework.
For non-prefixed headers, include path is $PREFIX/include/KF5.
Is this correct?
Looks correct to me.
David pointed out on IRC this scheme would need a significant change
for
frameworks like KIO or Solid: includes to kio/foo.h would need to be
changed to KIO/foo.h, same with solid/* includes. Are you fine with
this?
I am, but that looks like a big breakage in source compatibility though.
:-)
Probably stupid idea: What about having kde4support install the
compatibility
headers for those?
Would they be in a separate directory such as 'kde4support'? In a
case-insensitive file system you can't have both /usr/include/KF5/kio and
/usr/include/KF5/KIO...
--
Nicolás
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RFC Rules for installation of header files
On Fri, Nov 15, 2013 at 5:24 PM, Aurélien Gâteau agat...@kde.org wrote:
On Thu, 14 Nov 2013 17:55:42 +0100, Kevin Ottens wrote:
On Thursday 14 November 2013 18:40:04 Aurélien Gâteau wrote:
Looks like we have an agreement then. Let me recap:
# Installation dir
All header files are installed in $PREFIX/include/KF5/$Framework.
This includes 'k' prefixed headers like kfoo and KFoo,
I assume you meant kfoo.h here.
non-prefixed headers such as bar.h and Bar, as well as special headers
such as ${framework}_export.h and ${framework}_version.h.
# Include path
For 'k' prefixed headers, include path is
$PREFIX/include/KF5/$Framework.
For non-prefixed headers, include path is $PREFIX/include/KF5.
Is this correct?
Looks correct to me.
David pointed out on IRC this scheme would need a significant change for
frameworks like KIO or Solid: includes to kio/foo.h would need to be
changed to KIO/foo.h, same with solid/* includes. Are you fine with
this?
Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
I think that we're making this too complex. I'd say that it should always
be prefixed, then the module can decide to export the module directory as
well.
Not mixing headers from different frameworks in a same directory sounds
like a good feature as well.
Also I'd say that clearly there's a differentiation between camelcase and
lowercase. IMHO:
good:
#include kio/job.h
#include Solid/Device
weird:
#include Solid/device.h
Aleix
PS: I would stop adding even more things to kde4support if it's not
extremely needed, it's crowded already.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RFC Rules for installation of header files
On Friday 15 November 2013 15:01:03 Nicolás Alvarez wrote: Would they be in a separate directory such as 'kde4support'? In a case-insensitive file system you can't have both /usr/include/KF5/kio and /usr/include/KF5/KIO... Yes, definitely what I had in mind. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RFC Rules for installation of header files
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)
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.
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
Re: RFC Rules for installation of header files
On Thursday 14 November 2013 18:04:57 Aurélien Gâteau 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.
In fact I initially mentionned $PREFIX/include/KF5/ because of your initial
proposal of having *_version.h and *_export.h one level up.
Do we want to support this as well? (I have no strong opinion on this
topic)
Honestly I don't have a strong opinion either. I'd say we probably don't want
it (they have it in Qt and we've seen the kind of issues it can create during
ports when something is splitted for instance). If it turns out to be
troublesome to not have it, we'll be able to reintroduce it later easily
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.
Right. Let's put them in the FrameworkName directory as well then.
Cheers.
--
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Fwd: RFC Rules for installation of header files
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
Re: RFC Rules for installation of header files
On 14.11.2013 18:20, Kevin Ottens wrote:
On Thursday 14 November 2013 18:04:57 Aurélien Gâteau 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.
In fact I initially mentionned $PREFIX/include/KF5/ because of your
initial
proposal of having *_version.h and *_export.h one level up.
Do we want to support this as well? (I have no strong opinion on
this
topic)
Honestly I don't have a strong opinion either. I'd say we probably
don't want
it (they have it in Qt and we've seen the kind of issues it can
create during
ports when something is splitted for instance). If it turns out to be
troublesome to not have it, we'll be able to reintroduce it later
easily
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.
Right. Let's put them in the FrameworkName directory as well then.
Looks like we have an agreement then. Let me recap:
# Installation dir
All header files are installed in $PREFIX/include/KF5/$Framework.
This includes 'k' prefixed headers like kfoo and KFoo,
non-prefixed headers such as bar.h and Bar, as well as special headers
such as ${framework}_export.h and ${framework}_version.h.
# Include path
For 'k' prefixed headers, include path is
$PREFIX/include/KF5/$Framework.
For non-prefixed headers, include path is $PREFIX/include/KF5.
Is this correct?
Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: RFC Rules for installation of header files
On 14.11.2013 18:31, Aleix Pol wrote:
On Thu, Nov 14, 2013 at 5:04 PM, Aurélien Gâteau agat...@kde.org
[3]
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
Mmm, this is not about installation path, but about the include path.
Does ecm_generate_headers affects the include path?
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.
Unless I am confused, Kevin proposal is to have only one folder:
$PREFIX/include/KF5/$Framework. This folder would contain both lower
case and camel case header files.
Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RFC Rules for installation of header files
On Thursday 14 November 2013 18:40:04 Aurélien Gâteau wrote:
Looks like we have an agreement then. Let me recap:
# Installation dir
All header files are installed in $PREFIX/include/KF5/$Framework.
This includes 'k' prefixed headers like kfoo and KFoo,
I assume you meant kfoo.h here.
non-prefixed headers such as bar.h and Bar, as well as special headers
such as ${framework}_export.h and ${framework}_version.h.
# Include path
For 'k' prefixed headers, include path is
$PREFIX/include/KF5/$Framework.
For non-prefixed headers, include path is $PREFIX/include/KF5.
Is this correct?
Looks correct to me.
Cheers.
--
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: RFC Rules for installation of header files
On Thursday 14 November 2013 18:43:59 Aleix Pol wrote:
On 14.11.2013 18:31, Aleix Pol wrote:
On Thu, Nov 14, 2013 at 5:04 PM, Aurélien Gâteau agat...@kde.org
[3]
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
Mmm, this is not about installation path, but about the include path.
Does ecm_generate_headers affects the include path?
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.
Unless I am confused, Kevin proposal is to have only one folder:
$PREFIX/include/KF5/$Framework. This folder would contain both lower
case and camel case header files.
Yes, that's what I propose.
Aurélien
This thread is confusing, I don't know who I'm replying to... From: said
Aleix, signature Aurélien... Did you guys merge or something? :-)
Cheers.
--
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: RFC Rules for installation of header files
This thread is confusing, I don't know who I'm replying to... From: said Aleix, signature Aurélien... Did you guys merge or something? :-) Nah, we did not. My webmail is screwed up and by default sets the From field to the sender of the mail I am replying to. Sorry Aleix for impersonating you. Just asked the support of my email host to look into that. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RFC Rules for installation of header files
On 14.11.2013 18:55, Kevin Ottens wrote: On Thursday 14 November 2013 18:40:04 Aurélien Gâteau wrote: Looks like we have an agreement then. Let me recap: # Installation dir All header files are installed in $PREFIX/include/KF5/$Framework. This includes 'k' prefixed headers like kfoo and KFoo, I assume you meant kfoo.h here. Oups, yes, indeed. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RFC Rules for installation of header files
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.
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.
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?
Cheers.
--
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RFC Rules for installation of header files
On 06/11/13 13:52, Aurélien Gâteau wrote:
## Most likely needed for SC
Those headers were already there in KDE4.
- conversion_check.h
- fixx11h.h
- kgenericfactory.tcc
- netwm_def.h
- netwm.h
- predicateproperties.h
- threadweaver installs headers as {lowercase}/{CamelCase}.h, instead of
{lowercase}/{lowercase}.h
- KDE/kdbgstream
- KDE/kndbgstream
- KDE/NET
- KDE/NETRootInfo
- KDE/NETWinInfo
- KDE/OrgKdeKDirNotifyInterface
- KDE/PtyProcess: this one comes from kdesu, but there is also
KPtyProcess (from kpty). That is potentially confusing.
- KDE/SshProcess
- KDE/StubProcess
- KDE/SuProcess
- KDE/ThumbCreator
- khtml installs CamelCase headers in KDE/khtml, instead of KDE/KHTML.
One option would be to create/generate compatibility headers that
contained #warning directives telling people to update their #includes
(at least for the headers that do not just contain deprecated code,
like predicateproperties.h). That would allow us to ditch them at KF6
time.
Makes sense.
We might also be willing to break SC for those headers that are not
very commonly used (conversion_check.h, for example, appears to be
internal API that is only installed for the benefit of inline code).
Indeed, in the case of conversion_check.h: it is installed because
kconfiggroup.h includes it. Might be worth renaming it to
kconfiggroup_internal.h, or just inline its content in kconfiggroup.h
itself (it's only 120 lines, including license header).
Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
RFC Rules for installation of header files
Yesterday frameworks meeting spawned a discussion regarding folders in
header files.
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.
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}.
In this situation, framework users are expected to use the framework
name in their #include directives. For example, code using the Sonnet
ConfigDialog class should use:
#include Sonnet/ConfigDialog
Some special files should still go in include:
{lowercaseframework}_export.h
{lowercaseframework}_version.h
This means the CMake target for the framework should always define its
include dirs as include and include/KDE, regardless of whether the
framework include files are grouped in a folder or not.
Do these rules make sense to you?
# Current situation
I wrote a quick script to list files which do not satisfy those rules.
(See attached, run it in the include dir, preferably after running 'make
install DESTDIR=/somewhere' to avoid finding headers from other
projects)
## Most likely needed for SC
Those headers were already there in KDE4.
- conversion_check.h
- fixx11h.h
- kgenericfactory.tcc
- netwm_def.h
- netwm.h
- predicateproperties.h
- threadweaver installs headers as {lowercase}/{CamelCase}.h, instead of
{lowercase}/{lowercase}.h
- KDE/kdbgstream
- KDE/kndbgstream
- KDE/NET
- KDE/NETRootInfo
- KDE/NETWinInfo
- KDE/OrgKdeKDirNotifyInterface
- KDE/PtyProcess: this one comes from kdesu, but there is also
KPtyProcess (from kpty). That is potentially confusing.
- KDE/SshProcess
- KDE/StubProcess
- KDE/SuProcess
- KDE/ThumbCreator
- khtml installs CamelCase headers in KDE/khtml, instead of KDE/KHTML.
## Fixable
- config-kwindowsystem.h: Should not be installed
- kfilewrite.desktop: (!?) Most likely a typo. KDE4 version is in
share/kde4/servicetypes/
- KJsEmbed/kjsembed_export.h: Should be installed in include. Or should
not be installed at all since KJsEmbed does not install any other
header (!?)
- lineediturldropeventfilter.h: New in 5.0. Class should be prefixed
with 'K', file should be prefixed with 'k'.
kjs and wtf install some headers as {lowercase}/{CamelCase}.h instead of
{lowercase}/{lowercase}.h. Those headers were not installed before so
this could be fixed without breaking SC.
Aurélien
#!/bin/sh
set -e
# Quick'n'dirty way to generate a pattern file for include rules from a
# commented list
grep -v -e '^#' -e '^$' /tmp/patterns EOF
# Special files: *_export.h, *_version.h,...
^[a-z]+_export\.h
^[a-z]+_version\.h
^qtest_kde\.h
# k{lowercase}.h
^k[a-z0-9_]+\.h
# {lowercase}/{lowercase}.h
^([-a-z0-9]+/)+[a-z0-9_]+\.h
# KDE/K{CamelCase}
^KDE/K[A-Z][a-zA-Z]+
# KDE/{CamelCase}/{CamelCase}
^KDE/([A-Z][a-zA-Z]+/)+[a-zA-Z]+
# Exceptions (uncomment to make the list more readable)
# threadweaver, kjs, wtf:
# {lowercase}/{CamelCase}.h
# ^(threadweaver|kjs|wtf)/[A-Z][a-zA-Z0-9_]+\.h
# khtml:
# KDE/{lowercase}/{CamelCase}
# ^KDE/khtml/[a-zA-Z]+
# Ignore Qt includes
#^Qt[A-Z][a-zA-Z0-9]+/
# Ignore Phonon includes. Phonon is strange! it installs everything in a phonon4qt5 folder
#^phonon4qt5/
EOF
find -type f | sed 's,^./,,' | egrep -v -f /tmp/patterns___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RFC Rules for installation of header files
On 06/11/13 13:52, Aurélien Gâteau wrote:
## Most likely needed for SC
Those headers were already there in KDE4.
- conversion_check.h
- fixx11h.h
- kgenericfactory.tcc
- netwm_def.h
- netwm.h
- predicateproperties.h
- threadweaver installs headers as {lowercase}/{CamelCase}.h, instead of
{lowercase}/{lowercase}.h
- KDE/kdbgstream
- KDE/kndbgstream
- KDE/NET
- KDE/NETRootInfo
- KDE/NETWinInfo
- KDE/OrgKdeKDirNotifyInterface
- KDE/PtyProcess: this one comes from kdesu, but there is also
KPtyProcess (from kpty). That is potentially confusing.
- KDE/SshProcess
- KDE/StubProcess
- KDE/SuProcess
- KDE/ThumbCreator
- khtml installs CamelCase headers in KDE/khtml, instead of KDE/KHTML.
One option would be to create/generate compatibility headers that
contained #warning directives telling people to update their #includes
(at least for the headers that do not just contain deprecated code, like
predicateproperties.h). That would allow us to ditch them at KF6 time.
We might also be willing to break SC for those headers that are not very
commonly used (conversion_check.h, for example, appears to be internal
API that is only installed for the benefit of inline code).
Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
