Re: KNewStuff3 vs. KNS3 vs. KNewStuff (was: Re: What are the plans with CamelCase includes?)
On Saturday 11 January 2014 02:42:20 Friedrich W. H. Kossebau wrote: There the used namespace does not match the module name: namespace is KNS3, the module name KNewStuff3. That's not a problem, the KIOCore module uses namespace (and therefore prefix) KIO. I just saw this mail, after my reply to reviewboard. It seems that I missed one thing: that the actual C++ namespace is KNS3. Then there is indeed the option of making it KNS3/File and kns3/file.h, for more consistency (this time with the C++ namespace), at the cost of a greater SIC. But you could install knewstuff3/file.h forwarding headers for compatibility. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KNewStuff3 vs. KNS3 vs. KNewStuff (was: Re: What are the plans with CamelCase includes?)
Am Montag, 13. Januar 2014, 09:40:57 schrieb David Faure: On Saturday 11 January 2014 02:42:20 Friedrich W. H. Kossebau wrote: There the used namespace does not match the module name: namespace is KNS3, the module name KNewStuff3. That's not a problem, the KIOCore module uses namespace (and therefore prefix) KIO. I just saw this mail, after my reply to reviewboard. It seems that I missed one thing: that the actual C++ namespace is KNS3. (And I missed before that PREFIX is also used for generating the forwarding path inside the CamelCase header, tested before only with KNewStuff3 as prefix and then did change to KNS3 without e.g. recompiling Okteta, just did make install in frameworks/knewstuff and that worked (tm), blame on me :) ) Then there is indeed the option of making it KNS3/File and kns3/file.h, for more consistency (this time with the C++ namespace), at the cost of a greater SIC. But you could install knewstuff3/file.h forwarding headers for compatibility. Would agree that this option is the more consistent one. Those knewstuff3/file.h forwarding headers you are proposing, they would be installed from KDE4Support, right? To [...]/include/KF5/knewstuff3, with the pattern... file entry.h contains: #include kns3/entry.h And all include/KF5/KDE/KNS3/* forwarding headers would be changed from #include knewstuff3/file.h to #include kns3/file.h as well. Would update/prepare RRs for both kde4support and knewstuff modules, if I got the proposal right and noone objects. Cheers Friedrich ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KNewStuff3 vs. KNS3 vs. KNewStuff (was: Re: What are the plans with CamelCase includes?)
On Monday 13 January 2014 17:50:25 Friedrich W. H. Kossebau wrote: Those knewstuff3/file.h forwarding headers you are proposing, they would be installed from KDE4Support, right? To [...]/include/KF5/knewstuff3, with the pattern... file entry.h contains: #include kns3/entry.h Ah, good idea. There's a bunch of forwarding headers I wrote for SC reasons that should move to kde4support too... Well, including knewstuffbutton.h, for knewstuff. You'll move it too? And all include/KF5/KDE/KNS3/* forwarding headers would be changed from #include knewstuff3/file.h to #include kns3/file.h as well. Yep. Would update/prepare RRs for both kde4support and knewstuff modules, if I got the proposal right and noone objects. Sounds good to me. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KNewStuff3 vs. KNS3 vs. KNewStuff (was: Re: What are the plans with CamelCase includes?)
Am Donnerstag, 2. Januar 2014, 15:30:20 schrieb David Faure:
On Thursday 02 January 2014 14:06:47 Kevin Ottens wrote:
On Thursday 02 January 2014 12:25:47 David Faure wrote:
On Thursday 02 January 2014 11:35:43 David Faure wrote:
See attached patch.
I forgot to attach the corresponding patch for ECM.
Tested on KParts too, with the addition of a PREFIX variable.
MODULE_NAME = KParts or KIOCore .. the include dir under KF5, always
titlecase PREFIX = KParts or KIO, the subdir inside MODULE_NAME for
namespaced headers, gets lowercased for lowercase headers.
include/KF5/KParts/KParts/BrowserExtension
include/KF5/KParts/kparts/browserextension.h
Awaiting for green light.
That would be for the namespaced frameworks only right?
We still plan to have:
include/KF5/KCoreAddons/kjob.h
include/KF5/KCoreAddons/KJob
For the non namespace case?
Yes.
include/KF5/MODULE_NAME/the_thing_to_include
where the_thing_to_include can include a prefix (namespaced headers) or not
(non-namespaced headers).
I can see how it looks like duplication when the prefix is equal to the
module name, but since it's not always the case (KIOCore vs KIO) and since
there isn't always a prefix (non-namespaced headers), I think this makes
things consistent.
What about KNewStuff3 forward headers?
There the used namespace does not match the module name:
namespace is KNS3, the module name KNewStuff3.
To confuse things, the name of the repo and in the framework is just knewstuff
or KNewStuff, without the postfix 3, duh.
What about changing the namespace to KNewStuff in the framework, and making
the KNS3 namespace an alias for it in the kde4support headers? Ah, not
possible, the namespace is in the signature of some headers, so connections
with SIGNAL() do pick that up literally, ignoring the namespace alias. Bummer.
So KNS3 or KNewStuff3 for the prefix? I would opt for KNS3 to match the
namespace, see attached patch. Currently the prefix is lowercase, thus wrong
anyway :)
Cheers
Friedrichdiff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 05cd500..f217173 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -90,7 +90,7 @@ ecm_generate_headers(
MODULE_NAME KNewStuff3
REQUIRED_HEADERS KNewStuff_HEADERS
- PREFIX knewstuff3
+ PREFIX KNS3
)
install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/KNewStuff3 DESTINATION ${INCLUDE_INSTALL_DIR} COMPONENT Devel)
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
On Thursday 02 January 2014 07:45:12 Kevin Ottens wrote:
On Thursday 02 January 2014 00:31:05 David Faure wrote:
On Tuesday 31 December 2013 14:48:13 Aleix Pol wrote:
-- Up-to-date:
/d/kde/inst/kde_frameworks/include/KF5/kcoreaddons/kaboutdata.h
-- Up-to-date:
/d/kde/inst/kde_frameworks/include/KF5/KCoreAddons/KAboutData
The email thread RFC Rules for installation of header files does say
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}.
Actually, what's the reason for lowercaseframework there?
I used that in all the modules I converted (except KIO, I just realized),
and I'm wondering what the point is.
Example:
include/KF5/KIOCore/KFileItem
include/KF5/KIOCore/kfileitem.h
works fine with KIOCore in the include path, apps just include KFileItem
or kfileitem.h
If I fix it to
include/KF5/KIOCore/KFileItem
include/KF5/kiocore/kfileitem.h [all lowercase]
it will of course work too, with both dirs in the include path.
It's all transparent for the apps either way, since the cmake magic
encapsulates it for the them.
I'm just wondering what's the point in using two different dirs for
kfileitem.h and KFileItem?
This wasn't intended I guess. When the discussion about include files
occured the consensus was to have everything in a single directory (the
camel cased one).
OK I initially thought it was so the implementation of ecm_generate_headers is
simpler (lowercase everything), but in fact that's not it, it lowercases
individual parts explicitely.
In fact if we only use a camelcase header, the CMakeLists.txt code is even
simpler because the INSTALL(DIRECTORY) line will install both kinds of
headers. Which removes the need for the KCoreAddons_HEADERS variable
altogether.
See attached patch.
Aleix, any objections?
I'll script this over all modules, if not.
I think the reasoning might have been: so that people can include
kcoreaddons/krandom.h. But I'm not sure we even want to allow that.
It breaks the whole idea that the install dir is transparent to the apps,
the idea of compile-time errors (header not found) when not linking to the
appropriate lib, and of course it will break when we move stuff around for
kf6.
Well, we can't physically prevent people from writing #include
KCoreAddons/krandom.h or KCoreAddons/KRandom, but the fact that the first
one looks weird will at least reduce the chances of people doing that :)
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
diff --git a/src/lib/CMakeLists.txt b/src/lib/CMakeLists.txt
index 4496ea9..5947515 100644
--- a/src/lib/CMakeLists.txt
+++ b/src/lib/CMakeLists.txt
@@ -96,7 +96,7 @@ else()
target_link_libraries(KF5CoreAddons PRIVATE netapi32)
endif()
-target_include_directories(KF5CoreAddons INTERFACE $INSTALL_INTERFACE:${INCLUDE_INSTALL_DIR}/kcoreaddons;${INCLUDE_INSTALL_DIR}/KCoreAddons )
+target_include_directories(KF5CoreAddons INTERFACE $INSTALL_INTERFACE:${INCLUDE_INSTALL_DIR}/KCoreAddons )
target_compile_definitions(KF5CoreAddons INTERFACE $INSTALL_INTERFACE:KCOREADDONS_LIB)
@@ -108,13 +108,11 @@ set_target_properties(KF5CoreAddons PROPERTIES VERSION ${KCOREADDONS_VERSION_S
ecm_generate_headers(
KAboutData
- REQUIRED_HEADERS KCoreAddons_HEADERS
)
ecm_generate_headers(
KSharedDataCache
RELATIVE caching
- REQUIRED_HEADERS KCoreAddons_HEADERS
)
ecm_generate_headers(
KAutoSaveFile
@@ -125,7 +123,6 @@ ecm_generate_headers(
KUrlMimeData
RELATIVE io
- REQUIRED_HEADERS KCoreAddons_HEADERS
)
ecm_generate_headers(
KCompositeJob
@@ -134,21 +131,18 @@ ecm_generate_headers(
KJobUiDelegate
RELATIVE jobs
- REQUIRED_HEADERS KCoreAddons_HEADERS
)
ecm_generate_headers(
KRandom
KRandomSequence
RELATIVE randomness
- REQUIRED_HEADERS KCoreAddons_HEADERS
)
ecm_generate_headers(
KMacroExpander
KStringHandler
RELATIVE text
- REQUIRED_HEADERS KCoreAddons_HEADERS
)
ecm_generate_headers(
KFormat
@@ -156,15 +150,13 @@ ecm_generate_headers(
KShell
RELATIVE util
- REQUIRED_HEADERS KCoreAddons_HEADERS
)
install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/KCoreAddons DESTINATION ${INCLUDE_INSTALL_DIR} COMPONENT Devel )
install(TARGETS KF5CoreAddons EXPORT KF5CoreAddonsTargets ${INSTALL_TARGETS_DEFAULT_ARGS})
install(FILES
-${KCoreAddons_HEADERS}
io/kfilesystemtype_p.h #Needed for building kio, KFileSystemType
${CMAKE_CURRENT_BINARY_DIR}/kcoreaddons_export.h
-DESTINATION ${INCLUDE_INSTALL_DIR}/kcoreaddons COMPONENT Devel
+DESTINATION ${INCLUDE_INSTALL_DIR}/KCoreAddons COMPONENT Devel
)
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
Re: What are the plans with CamelCase includes?
This wasn't intended I guess. When the discussion about include files occured the consensus was to have everything in a single directory (the camel cased one). OK I initially thought it was so the implementation of ecm_generate_headers is simpler (lowercase everything), but in fact that's not it, it lowercases individual parts explicitely. In fact if we only use a camelcase header, the CMakeLists.txt code is even simpler because the INSTALL(DIRECTORY) line will install both kinds of headers. Which removes the need for the KCoreAddons_HEADERS variable altogether. See attached patch. Aleix, any objections? I'll script this over all modules, if not. I think the reasoning might have been: so that people can include kcoreaddons/krandom.h. But I'm not sure we even want to allow that. It breaks the whole idea that the install dir is transparent to the apps, the idea of compile-time errors (header not found) when not linking to the appropriate lib, and of course it will break when we move stuff around for kf6. Well, we can't physically prevent people from writing #include KCoreAddons/krandom.h or KCoreAddons/KRandom, but the fact that the first one looks weird will at least reduce the chances of people doing that :) Hmm, just a question for the case, that we have a namespace, like KTextEditor. At the moment we install (e.g. for KTextEditor::View): KTextEditor/View and ktexteditor/view.h Will that change still make that possible? Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
On Thursday 02 January 2014 11:42:57 Christoph Cullmann wrote: This wasn't intended I guess. When the discussion about include files occured the consensus was to have everything in a single directory (the camel cased one). OK I initially thought it was so the implementation of ecm_generate_headers is simpler (lowercase everything), but in fact that's not it, it lowercases individual parts explicitely. In fact if we only use a camelcase header, the CMakeLists.txt code is even simpler because the INSTALL(DIRECTORY) line will install both kinds of headers. Which removes the need for the KCoreAddons_HEADERS variable altogether. See attached patch. Aleix, any objections? I'll script this over all modules, if not. I think the reasoning might have been: so that people can include kcoreaddons/krandom.h. But I'm not sure we even want to allow that. It breaks the whole idea that the install dir is transparent to the apps, the idea of compile-time errors (header not found) when not linking to the appropriate lib, and of course it will break when we move stuff around for kf6. Well, we can't physically prevent people from writing #include KCoreAddons/krandom.h or KCoreAddons/KRandom, but the fact that the first one looks weird will at least reduce the chances of people doing that :) Hmm, just a question for the case, that we have a namespace, like KTextEditor. At the moment we install (e.g. for KTextEditor::View): KTextEditor/View and ktexteditor/view.h Will that change still make that possible? Ah, good point. The answer is: yes, if we put both under the framework name. If the framework is called KTextEditor, then this would lead to include/KF5/KTextEditor/KTextEditor/View include/KF5/KTextEditor/ktexteditor/view.h The benefit of that is that when an app forgets to link to KTextEditor, [which adds include/KF5/KTextEditor to the include path] the includes won't work. With the current solution, they will still work, which is inconsistent with non-namespaced headers. I already set things up this way for KIO, which has both namespaced and non- namespaced headers. include/KF5/KIOCore/KIO/ListJob include/KF5/KIOCore/kio/listjob.h Note the difference between the framework name (KIOCore) and the namespace (KIO), so it looks like it makes more sense here than when writing KTextEditor/KTextEditor - but that's just because your framework name matches your namespace name :-) What do you think? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
- Ursprüngliche Mail - Hmm, just a question for the case, that we have a namespace, like KTextEditor. At the moment we install (e.g. for KTextEditor::View): KTextEditor/View and ktexteditor/view.h Will that change still make that possible? Ah, good point. The answer is: yes, if we put both under the framework name. If the framework is called KTextEditor, then this would lead to include/KF5/KTextEditor/KTextEditor/View include/KF5/KTextEditor/ktexteditor/view.h The benefit of that is that when an app forgets to link to KTextEditor, [which adds include/KF5/KTextEditor to the include path] the includes won't work. With the current solution, they will still work, which is inconsistent with non-namespaced headers. I already set things up this way for KIO, which has both namespaced and non- namespaced headers. include/KF5/KIOCore/KIO/ListJob include/KF5/KIOCore/kio/listjob.h Note the difference between the framework name (KIOCore) and the namespace (KIO), so it looks like it makes more sense here than when writing KTextEditor/KTextEditor - but that's just because your framework name matches your namespace name :-) What do you think? Yeah, that sounds sane enough, even if in my case it would look duplicated ;) But the benefit of not found headers if wrong link flags is really nice! Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
On Thursday 02 January 2014 11:35:43 David Faure wrote:
See attached patch.
I forgot to attach the corresponding patch for ECM.
Tested on KParts too, with the addition of a PREFIX variable.
MODULE_NAME = KParts or KIOCore .. the include dir under KF5, always titlecase
PREFIX = KParts or KIO, the subdir inside MODULE_NAME for namespaced headers,
gets lowercased for lowercase headers.
include/KF5/KParts/KParts/BrowserExtension
include/KF5/KParts/kparts/browserextension.h
Awaiting for green light.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
diff --git a/modules/ECMGenerateHeaders.cmake b/modules/ECMGenerateHeaders.cmake
index 7fac164..4e1923b 100644
--- a/modules/ECMGenerateHeaders.cmake
+++ b/modules/ECMGenerateHeaders.cmake
@@ -13,11 +13,14 @@
# ECM_GENERATE_HEADERS( ClassA ClassB ...
# [MODULE_NAME name]
# [OUTPUT_DIR path]
+# [PREFIX prefix]
# [REQUIRED_HEADERS variable])
#
# The MODULE_NAME argument is used to provide information about where the
-# directories will be generated. By default, PROJECT_NAME will be used in both
-# CamelCase and lowercase version.
+# directories will be generated. By default, PROJECT_NAME will be used.
+#
+# The optional PREFIX will be prepended to the filenames, e.g. PREFIX KParts
+# will generate KParts/Part and kparts/part.h
#
# The OUTPUT_DIR argument specifies where the files will be generated; this
# should be within the build directory. By default, CMAKE_CURRENT_BINARY_DIR
@@ -40,7 +43,7 @@
include(CMakeParseArguments)
function(ECM_GENERATE_HEADERS)
-set(oneValueArgs MODULE_NAME OUTPUT_DIR REQUIRED_HEADERS RELATIVE)
+set(oneValueArgs MODULE_NAME OUTPUT_DIR PREFIX REQUIRED_HEADERS RELATIVE)
cmake_parse_arguments(EGH ${oneValueArgs} ${ARGN})
if(NOT EGH_MODULE_NAME)
set(EGH_MODULE_NAME ${PROJECT_NAME})
@@ -50,11 +53,13 @@ function(ECM_GENERATE_HEADERS)
set(EGH_OUTPUT_DIR ${CMAKE_CURRENT_BINARY_DIR})
endif()
-string(TOLOWER ${EGH_MODULE_NAME} lowercasemodule)
+if (EGH_PREFIX)
+ string(TOLOWER ${EGH_PREFIX} lowercaseprefix)
+endif()
foreach(_CLASSNAME ${EGH_UNPARSED_ARGUMENTS})
string(TOLOWER ${_CLASSNAME} lowercaseclassname)
-set(REGULAR_HEADER_NAME ${EGH_OUTPUT_DIR}/${lowercasemodule}/${lowercaseclassname}.h)
-set(FANCY_HEADER_NAME ${EGH_OUTPUT_DIR}/${EGH_MODULE_NAME}/${_CLASSNAME})
+set(REGULAR_HEADER_NAME ${EGH_OUTPUT_DIR}/${EGH_MODULE_NAME}/${lowercaseprefix}/${lowercaseclassname}.h)
+set(FANCY_HEADER_NAME ${EGH_OUTPUT_DIR}/${EGH_MODULE_NAME}/${EGH_PREFIX}/${_CLASSNAME})
set(_actualheader ${CMAKE_CURRENT_SOURCE_DIR}/${EGH_RELATIVE}/${lowercaseclassname}.h)
if (NOT EXISTS ${_actualheader})
message(FATAL_ERROR Could not find \${_actualheader}\)
@@ -63,7 +68,7 @@ function(ECM_GENERATE_HEADERS)
file(WRITE ${REGULAR_HEADER_NAME} #include \${_actualheader}\\n)
endif()
if (NOT EXISTS ${FANCY_HEADER_NAME})
-file(WRITE ${FANCY_HEADER_NAME} #include \${lowercasemodule}/${lowercaseclassname}.h\\n)
+file(WRITE ${FANCY_HEADER_NAME} #include \${lowercaseprefix}/${lowercaseclassname}.h\\n)
endif()
list(APPEND REQUIRED_HEADERS ${_actualheader})
endforeach()
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
On Thursday 02 January 2014 12:25:47 David Faure wrote: On Thursday 02 January 2014 11:35:43 David Faure wrote: See attached patch. I forgot to attach the corresponding patch for ECM. Tested on KParts too, with the addition of a PREFIX variable. MODULE_NAME = KParts or KIOCore .. the include dir under KF5, always titlecase PREFIX = KParts or KIO, the subdir inside MODULE_NAME for namespaced headers, gets lowercased for lowercase headers. include/KF5/KParts/KParts/BrowserExtension include/KF5/KParts/kparts/browserextension.h Awaiting for green light. That would be for the namespaced frameworks only right? We still plan to have: include/KF5/KCoreAddons/kjob.h include/KF5/KCoreAddons/KJob For the non namespace case? That's what I understand from your previous patch but I'd like to be sure I'm not missing something. 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: What are the plans with CamelCase includes?
On Thu, Jan 2, 2014 at 12:31 AM, David Faure fa...@kde.org wrote:
On Tuesday 31 December 2013 14:48:13 Aleix Pol wrote:
-- Up-to-date:
/d/kde/inst/kde_frameworks/include/KF5/kcoreaddons/kaboutdata.h
-- Up-to-date:
/d/kde/inst/kde_frameworks/include/KF5/KCoreAddons/KAboutData
The email thread RFC Rules for installation of header files does say
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}.
Actually, what's the reason for lowercaseframework there?
I used that in all the modules I converted (except KIO, I just realized),
and
I'm wondering what the point is.
Example:
include/KF5/KIOCore/KFileItem
include/KF5/KIOCore/kfileitem.h
works fine with KIOCore in the include path, apps just include KFileItem
or
kfileitem.h
If I fix it to
include/KF5/KIOCore/KFileItem
include/KF5/kiocore/kfileitem.h [all lowercase]
it will of course work too, with both dirs in the include path.
It's all transparent for the apps either way, since the cmake magic
encapsulates it for the them.
I'm just wondering what's the point in using two different dirs for
kfileitem.h and KFileItem?
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
I did it like that because KParts works this way. Of course, it's not
required on other modules.
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
On Thursday 02 January 2014 14:06:47 Kevin Ottens wrote: On Thursday 02 January 2014 12:25:47 David Faure wrote: On Thursday 02 January 2014 11:35:43 David Faure wrote: See attached patch. I forgot to attach the corresponding patch for ECM. Tested on KParts too, with the addition of a PREFIX variable. MODULE_NAME = KParts or KIOCore .. the include dir under KF5, always titlecase PREFIX = KParts or KIO, the subdir inside MODULE_NAME for namespaced headers, gets lowercased for lowercase headers. include/KF5/KParts/KParts/BrowserExtension include/KF5/KParts/kparts/browserextension.h Awaiting for green light. That would be for the namespaced frameworks only right? We still plan to have: include/KF5/KCoreAddons/kjob.h include/KF5/KCoreAddons/KJob For the non namespace case? Yes. include/KF5/MODULE_NAME/the_thing_to_include where the_thing_to_include can include a prefix (namespaced headers) or not (non-namespaced headers). I can see how it looks like duplication when the prefix is equal to the module name, but since it's not always the case (KIOCore vs KIO) and since there isn't always a prefix (non-namespaced headers), I think this makes things consistent. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
On Thursday 02 January 2014 12:25:47 David Faure wrote: Awaiting for green light. /me waves the green light. 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: What are the plans with CamelCase includes?
On Tuesday 31 December 2013 14:48:13 Aleix Pol wrote:
-- Up-to-date:
/d/kde/inst/kde_frameworks/include/KF5/kcoreaddons/kaboutdata.h
-- Up-to-date:
/d/kde/inst/kde_frameworks/include/KF5/KCoreAddons/KAboutData
The email thread RFC Rules for installation of header files does say
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}.
Actually, what's the reason for lowercaseframework there?
I used that in all the modules I converted (except KIO, I just realized), and
I'm wondering what the point is.
Example:
include/KF5/KIOCore/KFileItem
include/KF5/KIOCore/kfileitem.h
works fine with KIOCore in the include path, apps just include KFileItem or
kfileitem.h
If I fix it to
include/KF5/KIOCore/KFileItem
include/KF5/kiocore/kfileitem.h [all lowercase]
it will of course work too, with both dirs in the include path.
It's all transparent for the apps either way, since the cmake magic
encapsulates it for the them.
I'm just wondering what's the point in using two different dirs for
kfileitem.h and KFileItem?
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
On Thursday 02 January 2014 00:31:05 David Faure wrote:
On Tuesday 31 December 2013 14:48:13 Aleix Pol wrote:
-- Up-to-date:
/d/kde/inst/kde_frameworks/include/KF5/kcoreaddons/kaboutdata.h
-- Up-to-date:
/d/kde/inst/kde_frameworks/include/KF5/KCoreAddons/KAboutData
The email thread RFC Rules for installation of header files does say
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}.
Actually, what's the reason for lowercaseframework there?
I used that in all the modules I converted (except KIO, I just realized),
and I'm wondering what the point is.
Example:
include/KF5/KIOCore/KFileItem
include/KF5/KIOCore/kfileitem.h
works fine with KIOCore in the include path, apps just include KFileItem
or kfileitem.h
If I fix it to
include/KF5/KIOCore/KFileItem
include/KF5/kiocore/kfileitem.h [all lowercase]
it will of course work too, with both dirs in the include path.
It's all transparent for the apps either way, since the cmake magic
encapsulates it for the them.
I'm just wondering what's the point in using two different dirs for
kfileitem.h and KFileItem?
This wasn't intended I guess. When the discussion about include files occured
the consensus was to have everything in a single directory (the camel cased
one).
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: What are the plans with CamelCase includes?
On Sunday 29 December 2013 23:23:44 Friedrich W. H. Kossebau wrote:
Am Sonntag, 29. Dezember 2013, 17:39:47 schrieb Kevin Ottens:
On Sunday 29 December 2013 17:11:36 Friedrich W. H. Kossebau wrote:
So possibly something more that needs to be decided on: where should
plain headers end up?
Consensus was: same place. The camel cased includes and the .h ones were
planned to live in the same folder.
To have the same pattern like Qt5 uses, I guess? Makes also sense to me.
So by example of KI18n:
Instead of
include/KF5/klocalizedstring.h
include/KF5/KI18n/KLocalizedString
there should be
include/KF5/KI18n/klocalizedstring.h
include/KF5/KI18n/KLocalizedString
right?
No,
include/KF5/ki18n/klocalizedstring.h
include/KF5/KI18n/KLocalizedString
(lowercase ki18n in the first line).
See make install in kcoreaddons now:
-- Up-to-date: /d/kde/inst/kde_frameworks/include/KF5/kcoreaddons/kaboutdata.h
-- Up-to-date: /d/kde/inst/kde_frameworks/include/KF5/KCoreAddons/KAboutData
The email thread RFC Rules for installation of header files does say
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}.
Aleix, is there a final version of that RFC in a wiki page maybe, so we can
all make sure we refer to the same spec for this?
(kuitmarkup.h possibly was not renamed to kuitsetup.h for backward support)
And KF5I18nTargets.cmake should have both:
INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include/KF5
INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include/KF5/KI18n
Yes, see the KCoreAddonsTargets file ;)
Now, what to expect for frameworks not using the K* prefix for their
classes (and generally using namespaces), by example of KParts:
include/KF5/KParts/KParts/StatusBarExtension
include/KF5/KParts/KParts/ListingExtension
include/KF5/KParts/kparts/statusbarextension.h
include/KF5/KParts/kparts/browseropenorsavequestion.h
I think this is what we should have, but the RFC thread isn't really clear to
me, hence my request for a final spec.
More questions:
Q: Really hardcode KF5/ prefix to include path?
The KF5/ part of the include path, does it make sense in all deployments
given that all headers are already contained in subdirs? IMHO that should
be left to be defined by the packager/installer. For what reason would we
want to enforce that?
For co-installability in /usr/include.
Will there be any files outside of the $MODULENAME/ subdirs?
I don't think so.
Q: Add a convenience Module/Module file?
What about adding a convenience include-all file Module/Module, e.g.
include/KF5/KI18n/KI18n, like there usually is one with each Qt module?
I don't like them very much. They make compilation slower, and allow people to
be lazy instead of doing the right thing
In quick test programs they are fine, but they are quickly abused in real
code...
Well, I won't veto them (consistency is good), but I certainly won't spend
time on them.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
On Tue, Dec 31, 2013 at 12:50 PM, David Faure fa...@kde.org wrote:
On Sunday 29 December 2013 23:23:44 Friedrich W. H. Kossebau wrote:
Am Sonntag, 29. Dezember 2013, 17:39:47 schrieb Kevin Ottens:
On Sunday 29 December 2013 17:11:36 Friedrich W. H. Kossebau wrote:
So possibly something more that needs to be decided on: where should
plain headers end up?
Consensus was: same place. The camel cased includes and the .h ones
were
planned to live in the same folder.
To have the same pattern like Qt5 uses, I guess? Makes also sense to me.
So by example of KI18n:
Instead of
include/KF5/klocalizedstring.h
include/KF5/KI18n/KLocalizedString
there should be
include/KF5/KI18n/klocalizedstring.h
include/KF5/KI18n/KLocalizedString
right?
No,
include/KF5/ki18n/klocalizedstring.h
include/KF5/KI18n/KLocalizedString
(lowercase ki18n in the first line).
See make install in kcoreaddons now:
-- Up-to-date:
/d/kde/inst/kde_frameworks/include/KF5/kcoreaddons/kaboutdata.h
-- Up-to-date:
/d/kde/inst/kde_frameworks/include/KF5/KCoreAddons/KAboutData
The email thread RFC Rules for installation of header files does say
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}.
Aleix, is there a final version of that RFC in a wiki page maybe, so we can
all make sure we refer to the same spec for this?
Ok, maybe I should be changing the ones we have now CamelCased to KF5/KDE/.
Having a KDE namespace doesn't make much sense though, if the idea is not
to break source compatibility, we can just tell people to either depend on
KDE4Support or to move from KDE - {ModuleName}.
I don't know about any page on the wiki about headers structure. We really
need this.
(kuitmarkup.h possibly was not renamed to kuitsetup.h for backward
support)
And KF5I18nTargets.cmake should have both:
INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include/KF5
INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include/KF5/KI18n
Yes, see the KCoreAddonsTargets file ;)
Now, what to expect for frameworks not using the K* prefix for their
classes (and generally using namespaces), by example of KParts:
include/KF5/KParts/KParts/StatusBarExtension
include/KF5/KParts/KParts/ListingExtension
include/KF5/KParts/kparts/statusbarextension.h
include/KF5/KParts/kparts/browseropenorsavequestion.h
I think this is what we should have, but the RFC thread isn't really clear
to
me, hence my request for a final spec.
The RFC thread is more about whether include/.../KCoreAddons
and include/.../kcoreaddons should be by default in the include paths or
not.
More questions:
Q: Really hardcode KF5/ prefix to include path?
The KF5/ part of the include path, does it make sense in all deployments
given that all headers are already contained in subdirs? IMHO that should
be left to be defined by the packager/installer. For what reason would we
want to enforce that?
For co-installability in /usr/include.
I have another pro. This way you never include files without wanting to.
With the new headers structure you have to explicitly link against a module
to be able to find the headers of a framework. That's good, because it's
easier to diagnose a missing dependency from missing includes than weird
linker errors.
Will there be any files outside of the $MODULENAME/ subdirs?
I don't think so.
Q: Add a convenience Module/Module file?
What about adding a convenience include-all file Module/Module, e.g.
include/KF5/KI18n/KI18n, like there usually is one with each Qt module?
I don't like them very much. They make compilation slower, and allow
people to
be lazy instead of doing the right thing
In quick test programs they are fine, but they are quickly abused in real
code...
Well, I won't veto them (consistency is good), but I certainly won't spend
time on them.
AFAIK, it hasn't been discussed. Personally I've never been happy when
using those. I hear they're good when using precompiled headers, but I've
never experienced that myself.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
On Tuesday 31 December 2013 14:48:13 Aleix Pol wrote:
Ok, maybe I should be changing the ones we have now CamelCased to KF5/KDE/.
Having a KDE namespace doesn't make much sense though, if the idea is not
to break source compatibility, we can just tell people to either depend on
KDE4Support or to move from KDE - {ModuleName}.
Ah, for old-style #include KDE/KIcon?
Let's just script that away and make it #include KIcon.
We don't need a KDE prefix, we already have a KF5 prefix at install time.
This is the QtGui/QLabel thing again. Prefixes in the #include line create
future trouble when the prefix isn't related to the C++ class/namespace but
just arbitrary.
I don't know about any page on the wiki about headers structure. We really
need this.
(kuitmarkup.h possibly was not renamed to kuitsetup.h for backward
support)
And KF5I18nTargets.cmake should have both:
INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include/KF5
INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include/KF5/KI18n
Yes, see the KCoreAddonsTargets file ;)
Now, what to expect for frameworks not using the K* prefix for their
classes (and generally using namespaces), by example of KParts:
include/KF5/KParts/KParts/StatusBarExtension
include/KF5/KParts/KParts/ListingExtension
include/KF5/KParts/kparts/statusbarextension.h
include/KF5/KParts/kparts/browseropenorsavequestion.h
I think this is what we should have, but the RFC thread isn't really clear
to
me, hence my request for a final spec.
The RFC thread is more about whether include/.../KCoreAddons
and include/.../kcoreaddons should be by default in the include paths or
not.
Well, that much is clear, the answer is yes, we want #include kjob.h and
#include KJob, no prefix in the #include line.
But ... going back to the question of where we should install kparts
headers... I'm pretty sure you and Aurélien (and others, possibly) had come up
with a final solution, didn't you?
I have another pro. This way you never include files without wanting to.
With the new headers structure you have to explicitly link against a module
to be able to find the headers of a framework. That's good, because it's
easier to diagnose a missing dependency from missing includes than weird
linker errors.
Yes.
Q: Add a convenience Module/Module file?
AFAIK, it hasn't been discussed. Personally I've never been happy when
using those. I hear they're good when using precompiled headers, but I've
never experienced that myself.
Exactly: that's what they're good for, but in an opensource environment you
can't know what people are going to be using as setup for compiling (unlike a
more controlled internal-to-one-commercial-company setup), so we can't rely on
people having precompiled headers support.
However, with that argument, we could be providing all-in-one headers for the
benefit of commercial companies who can be sure they use precompiled
headers... Oh well, let's postpone this, it's more urgent to install the stuff
in the first place.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
Am Samstag, 28. Dezember 2013, 12:32:43 schrieb Kevin Ottens:
On Saturday 28 December 2013 11:55:56 David Faure wrote:
On Friday 27 December 2013 19:01:09 Friedrich W. H. Kossebau wrote:
So existing code ported from kdelibs would have to explicitely prefix
the
includes, e.g. be changed like
#include KLocalizedString - #include KI18n/KLocalizedString
Definitely don't want this.
See the QtGui/QLabel - QtWidgets/QLabel issue between Qt4 and Qt5, we
don't want to create the same problems with KDE Frameworks.
So yeah, I'm definitely in favour of *Targets.cmake files,
should include the path including the module prefix
Which is supposed to be the case as discussed in the thread with Aurélien a
while ago.
The complete consensus was IIRC:
- For frameworks with K* prefixed classes, the include line should be
#include KFoo;
- For frameworks not using the K* prefix for their classes (and generally
using namespaces) the include line should be #include Framework/Foo.
With the forward headers included, if the frameworks doesn't behave like
that it should be considered a bug.
Cheers.
Another problem with the current macro is that it expects the normal headers
in a path postfixed with the module name, by always writing the
CamelCase/forwarding headers like:
file(WRITE ${FANCY_HEADER_NAME}
#include \${lowercasemodule}/${lowercaseclassname}.h\\n)
e.g. resulting in [..]/include/KF5/KI18n/KLocalizedString containing
#include ki18n/klocalizedstring.h
Which of course will fail, as currently the plain *.h headers are installed
directly into the include path, not in a subdirectory named with the module
name. So possibly something more that needs to be decided on: where should
plain headers end up?
Cheers
Friedrich
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
On Sunday 29 December 2013 17:11:36 Friedrich W. H. Kossebau wrote:
Am Samstag, 28. Dezember 2013, 12:32:43 schrieb Kevin Ottens:
On Saturday 28 December 2013 11:55:56 David Faure wrote:
On Friday 27 December 2013 19:01:09 Friedrich W. H. Kossebau wrote:
So existing code ported from kdelibs would have to explicitely prefix
the
includes, e.g. be changed like
#include KLocalizedString - #include KI18n/KLocalizedString
Definitely don't want this.
See the QtGui/QLabel - QtWidgets/QLabel issue between Qt4 and Qt5, we
don't want to create the same problems with KDE Frameworks.
So yeah, I'm definitely in favour of *Targets.cmake files,
should include the path including the module prefix
Which is supposed to be the case as discussed in the thread with Aurélien
a
while ago.
The complete consensus was IIRC:
- For frameworks with K* prefixed classes, the include line should be
#include KFoo;
- For frameworks not using the K* prefix for their classes (and generally
using namespaces) the include line should be #include Framework/Foo.
With the forward headers included, if the frameworks doesn't behave like
that it should be considered a bug.
Cheers.
Another problem with the current macro is that it expects the normal headers
in a path postfixed with the module name, by always writing the
CamelCase/forwarding headers like:
file(WRITE ${FANCY_HEADER_NAME}
#include \${lowercasemodule}/${lowercaseclassname}.h\\n)
e.g. resulting in [..]/include/KF5/KI18n/KLocalizedString containing
#include ki18n/klocalizedstring.h
Which of course will fail, as currently the plain *.h headers are installed
directly into the include path, not in a subdirectory named with the module
name. So possibly something more that needs to be decided on: where should
plain headers end up?
Consensus was: same place. The camel cased includes and the .h ones were
planned to live in the same folder.
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: What are the plans with CamelCase includes?
Am Sonntag, 29. Dezember 2013, 17:39:47 schrieb Kevin Ottens:
On Sunday 29 December 2013 17:11:36 Friedrich W. H. Kossebau wrote:
So possibly something more that needs to be decided on: where should
plain headers end up?
Consensus was: same place. The camel cased includes and the .h ones were
planned to live in the same folder.
To have the same pattern like Qt5 uses, I guess? Makes also sense to me.
So by example of KI18n:
Instead of
include/KF5/ki18n_version.h
include/KF5/klocalizedstring.h
include/KF5/kuitmarkup.h
include/KF5/kuitsetup.h
include/KF5/ki18n_export.h
include/KF5/KI18n/KuitSetup
include/KF5/KI18n/KLocalizedString
there should be
include/KF5/KI18n/ki18n_version.h
include/KF5/KI18n/klocalizedstring.h
include/KF5/KI18n/kuitmarkup.h (has KuitSetup class def.)
include/KF5/KI18n/kuitsetup.h(forwards to kuitmarkup.h)
include/KF5/KI18n/ki18n_export.h
include/KF5/KI18n/KuitSetup
include/KF5/KI18n/KLocalizedString
right?
(kuitmarkup.h possibly was not renamed to kuitsetup.h for backward support)
And KF5I18nTargets.cmake should have both:
INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include/KF5
INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include/KF5/KI18n
Now, what to expect for frameworks not using the K* prefix for their classes
(and generally using namespaces), by example of KParts:
Currently it is:
include/KF5/KParts/StatusBarExtension
include/KF5/KParts/ListingExtension
include/KF5/kparts/statusbarextension.h
include/KF5/kparts/browseropenorsavequestion.h
[...]
What should that become?
include/KF5/KParts/KParts/StatusBarExtension
include/KF5/KParts/KParts/ListingExtension
include/KF5/KParts/kparts/statusbarextension.h
include/KF5/KParts/kparts/browseropenorsavequestion.h
[...]
KF5PartsTargets.cmake:
INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include/KF5
INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include/KF5/KParts
or rather
include/KF5/KParts/StatusBarExtension
include/KF5/KParts/ListingExtension
include/KF5/kparts/statusbarextension.h
include/KF5/kparts/browseropenorsavequestion.h
[...]
KF5PartsTargets.cmake just:
INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include/KF5
or else ?
More questions:
Q: Really hardcode KF5/ prefix to include path?
The KF5/ part of the include path, does it make sense in all deployments given
that all headers are already contained in subdirs? IMHO that should be left to
be defined by the packager/installer. For what reason would we want to enforce
that? Will there be any files outside of the $MODULENAME/ subdirs?
kdesupport/extra-cmake-modules/kde-modules/KDEInstallDirs.cmake has right now:
_set_fancy(INCLUDE_INSTALL_DIR
include/KF5The install dir for header files)
Q: Add a convenience Module/Module file?
What about adding a convenience include-all file Module/Module, e.g.
include/KF5/KI18n/KI18n, like there usually is one with each Qt module?
Cheers
Friedrich
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
On Friday 27 December 2013 19:01:09 Friedrich W. H. Kossebau wrote: So existing code ported from kdelibs would have to explicitely prefix the includes, e.g. be changed like #include KLocalizedString - #include KI18n/KLocalizedString Definitely don't want this. See the QtGui/QLabel - QtWidgets/QLabel issue between Qt4 and Qt5, we don't want to create the same problems with KDE Frameworks. So yeah, I'm definitely in favour of *Targets.cmake files, should include the path including the module prefix -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
On Saturday 28 December 2013 11:55:56 David Faure wrote: On Friday 27 December 2013 19:01:09 Friedrich W. H. Kossebau wrote: So existing code ported from kdelibs would have to explicitely prefix the includes, e.g. be changed like #include KLocalizedString - #include KI18n/KLocalizedString Definitely don't want this. See the QtGui/QLabel - QtWidgets/QLabel issue between Qt4 and Qt5, we don't want to create the same problems with KDE Frameworks. So yeah, I'm definitely in favour of *Targets.cmake files, should include the path including the module prefix Which is supposed to be the case as discussed in the thread with Aurélien a while ago. The complete consensus was IIRC: - For frameworks with K* prefixed classes, the include line should be #include KFoo; - For frameworks not using the K* prefix for their classes (and generally using namespaces) the include line should be #include Framework/Foo. With the forward headers included, if the frameworks doesn't behave like that it should be considered a bug. 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: What are the plans with CamelCase includes?
On 24/12/13 07:38, Friedrich W. H. Kossebau wrote: Hi, what are the plans with offering CamelCase includes in KF5 (e.g. #include KLocale)? On a quick search could not find anything mentioned somewhere. If I saw correctly, then currently CamelCase includes (for existing classes) are only available by KF5::KDE4Support, due to being the module which has those files and also installs them. Also the KF5/KDE seems somehow (not yet found out how) only added to the include dirs by listing that module in target_link_libraries. Is that also the long-term plan? (I hope not, because I like the CamelCase includes, and other people who use Qt with CamelCase includes, as offered, and want to use some KF5 modules would welcome to have them, too). Would be willing to help out with this. There were plans to auto-generate them. I'm not sure what happened with that. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
On Tue, Dec 24, 2013 at 12:14 PM, Alex Merry k...@randomguy3.me.uk wrote: On 24/12/13 07:38, Friedrich W. H. Kossebau wrote: Hi, what are the plans with offering CamelCase includes in KF5 (e.g. #include KLocale)? On a quick search could not find anything mentioned somewhere. If I saw correctly, then currently CamelCase includes (for existing classes) are only available by KF5::KDE4Support, due to being the module which has those files and also installs them. Also the KF5/KDE seems somehow (not yet found out how) only added to the include dirs by listing that module in target_link_libraries. Is that also the long-term plan? (I hope not, because I like the CamelCase includes, and other people who use Qt with CamelCase includes, as offered, and want to use some KF5 modules would welcome to have them, too). Would be willing to help out with this. There were plans to auto-generate them. I'm not sure what happened with that. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel We need to use ecm_generate_headers on every module. I'll try to take some time after the 26th to do it. If somebody wants to do it meanwhile, please do and I'll review it. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
Hello,
On Tue, Dec 24, 2013 at 5:59 PM, Aleix Pol aleix...@kde.org wrote:
I'll try to take some time after the 26th to do it. If somebody wants to do
it meanwhile, please do and I'll review it.
I have some spare time and want to do it.. If I want to check one
example for it.. the code in KParts repo is good one? That's what I
will need?
include(ECMGenerateHeaders)
ecm_generate_headers(
Part Plugin PartManager MainWindow Event
BrowserExtension HistoryProvider BrowserInterface
BrowserRun StatusBarExtension BrowserOpenOrSaveQuestion
ScriptableExtension TextExtension HtmlExtension FileInfoExtension
ListingExtension
)
install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/KParts DESTINATION
${INCLUDE_INSTALL_DIR} COMPONENT Devel )
Thanks!
--
Bhushan Shah
http://bhush9.github.io
IRC Nick : bshah on Freenode
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
