KDE-buildsystem-basics package ?

[Stephen Kelly]

Alexander Neundorf wrote:

> Hi,
> 
> any comments ?
> IOW: this is about introducing a small package which everything in KDE
> frameworks would depend on.

I see the problem, but I'm not a big fan of the proposed solution.


> 
> On Saturday 14 January 2012, Alexander Neundorf wrote:
>> Hi,
>> 
>> we have more or less the following groups of stuff in
>> FindKDE4Internals.cmake, KDE4Macros.cmake and KDE4Defaults.cmake:
>> 
>> Settings/switches/options:
>> * the install dirs [1]
>> > [1] I posted an email about our install dir issue to the cmake-
developers
> list: 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2595
> Brad explained that GNUInstallDirs.cmake is explicitely implementing the
> install dirs compatible to autotools, so it is meant for projects coming
> from there. Since this is not what we have in KDE, we do not necessarily
> have to use it. So basically he also recommends to have a separate
> solution for KDE for this. I agree with him on this.

The GNU equivalent lives in CMake. Could the KDE equivalent live in ECM 
sensibly? Couldn't a 3rd party follow the KDE framework conventions while 
not depending on an KDE libraries (eg Grantlee, or anything in kdesupport).

>> * the cmake policy settings

Any reason this needs to be global for all frameworks?

>> * typical settings, like KDE4_BUILD_TESTS

Looks like something that could go into CMake. Qt has a similar system. You 
can configure with -nomake tests, then cd to the tests dir and build 
individual tests.

>> , KDE4_ENABLE_FPIE

This isn't very different to other compiler and linker flags.

>> * RPATH settings

Also just a special case of linker flags? Or does this do something more?

>> * compiler and linker flags

I'm not sure how to handle this. I think it can sensibly be in ECM for the 
same reason as the install dirs (conforming to the KDE norms without 
depending on anything specifically KDE). Some compiler flags (and Qt flags 
like QT_STRICT_ITERATORS)are just sensible, and if building sensible 
software based on Qt they should be used.

I know you disagree.

>> * creating an uninstall target

Can it go into ECM?

>> 
>> Macros/functions:
>> * handling kcfg files

Installed from wherever KConfig lives.

>> * handling ui files
>> * handling widget files

What is the handling? Installed from KGuiAddons?

>> * handling ui3 files - still necessary ?

>> * handling documentation, docbook, manpages, ...

Not sure.

>> * handling icons

Installed from wherever KIconEngine lives.

>> * handling kdeinit

Installed from wherever kdeinit lives?

>> * kde4_add_plugin

Installed from wherever KPlugin lives? (Is KPlugin even needed anymore - 
Can't Qt get the needed extension hooks to make it obsolete?)

>> , kde4_add_unit_test, kde4_add_executable

I don't know. I'd be interested to see what they look like after removing 
the automoc stuff and seeing what's left and if refactoring is in order.

>> * dbus install stuff (kde4_install_auth_helper_files,
>> kde4_install_auth_actions)

I don't know. Are these helpers about permissions/authorisations? Does that 
mean it belongs with the KAuth stuff? Do we install any 'KDBus stuff'? If we 
do, they belong with that stuff.

>> 
>> 
>> Some of this stuff looks like it could be moved to a modularized lib:
>> UI: icon handling, ui, ui3 and widget file handlung
>> documentation: KDE4_ENABLE_HTMLHANDBOOK, handling documentation, docbook,
>> etc.
>> 
>> 
>> This still leaves most of the settings from the first section, and
>> several of the macros from the second section. 

Yes, if you agree with my assessments above, we might already have a smaller 
list that we can more easily tackle.

>> Especially things like
>> kde4_add_executable() and kde4_add_plugin() don't look like they belong
>> to some specific library.
>> 
>> 
>> So, I'd say we still need some place where this stuff can go:
>> * if there will be like one central very basic library this could be it.

That might mean adding a KDE dependency to everything in kdesupport (which 
have already decided not to have KDE dependencies).

>> * an extra kde subdirectory in extra-cmake-modules, but that doesn't feel
>> right

I don't see why it would need to be in a directory. It can just be a few 
files. Maybe even just one.

>> * an extra package kde-frameworks-buildsystem or something like this
>> 

Similar to above, that might mean adding a KDE dependency to everything in 
kdesupport (which have already decided not to have KDE dependencies).

Thanks,

Steve.