What are the plans with CamelCase includes?

Friedrich W. H. Kossebau kossebau at kde.org
Fri Dec 27 18:01:09 UTC 2013


Am Dienstag, 24. Dezember 2013, 18:17:48 schrieb Bhushan Shah:
> Hello,
> 
> On Tue, Dec 24, 2013 at 5:59 PM, Aleix Pol <aleixpol at 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 )

Ah, good, so there is already some macro even, and "just" needs some finishing 
and then application to all modules, right? Also seeing that there has been at 
least one related commit today. If you need people to help or test the results 
(e.g. updating Okteta to latest changes) just drag me in, can share a few 
hours per day these days.

Two questions I have right now:

A) Is there a policy for the frameworks that each public class should have a 
lowercase header? Seems the macro relies on that, but I am not sure if that 
already applies for all stuff coming from kdelibs. Does that need checking? 
Similar problem with extra namespaces for class-less functions perhaps.

B) What about the include dirs defined in the created *Targets.cmake files, 
should it include the path including the module prefix?

Currently there is just the "${_IMPORT_PREFIX}/include/KF5 defined, e.g. with 
KF5I18nTargets.cmake there is only
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include/KF5"
while the CamelCase headers are installed into include/KF5/KI18n

So existing code ported from kdelibs would have to explicitely prefix the 
includes, e.g. be changed like
#include <KLocalizedString> -> #include <KI18n/KLocalizedString>

With Qt by whatever magic it seems always also the paths including the module 
name are part of the include dirs. IMHO we ideally follow the patterns there, 
if possible. Any ideas for/about that?

Cheers
Friedrich


More information about the Kde-frameworks-devel mailing list