KDE-buildsystem-basics package ?

[Alexander Neundorf]

On Friday 20 January 2012, Stephen Kelly wrote:
> 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).

Well, by following the KDE conventions it would depend on something provided 
by KDE, not a library, but the package provided by KDE which contains those 
settings. It would be a build-time dependency to KDE.

> >> * the cmake policy settings
> 
> Any reason this needs to be global for all frameworks?

E.g. so that all macros und functions provided right now in KDE4Macros.cmake 
work as expected. E.g. the duplicate target names. Or to silence warnings if 
new policies are introduced, because KDE developers would think something has 
been broken. Or to enable the OLD behaviour, so that stuff they did before 
stays the recommended way to do it.
The average developer doesn't know about CMake policies, so we should preset 
them to what we consider sensible (or necessary in some cases).
 
> >> * typical settings, like KDE4_BUILD_TESTS
> 
> Looks like something that could go into CMake. 

I don't think so.
This is just a cmake option to be used to put around the directories where the 
tests reside. All it does is providing a common name for this option:
option(FOO ...)
if(FOO)
  add_subdirectory(tests)
endif()

> 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?

Well, it sets the cmake RPATH related settings.
The default is empty install RPATH. Everything else is project-specific, as 
our settings are KDE specific.

> >> * 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.

Well, I'd replace "... they should be used." with "...we think they should be 
used."
 
> >> * creating an uninstall target
> 
> Can it go into ECM?

Yes, maybe.
 
> >> 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.

kde4_add_unit_test() does not depend on anything, it is mostly just 
convenience. Same for all the compiler flags settings etc.

> >> * 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.

Not quite sure, Dario knows.

> >> 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.

Because the idea of e-c-m is to make stuff, which can be used independent from 
KDE (before this meant "no kdelibs", what does it mean then ?) available for 
non-KDE software.

Putting the cmake files, which kind of make an application a KDE application, 
there, turns e-c-m into a KDE package.
The KDE stuff which would be in there would not be general purpose, it is what 
we, the KDE developers, consider good for KDE applications and libraries.

So at the very least, I'd put that into a separate directory.

> >> * 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).

No, not really.
What is a "KDE dependency" ? A dependency to anything hosted by KDE ? Anything 
developed by KDE developers ?
Then e-c-m is also a "KDE dependency".

If e-c-m is not considered a "KDE dependency", then why should, let's call it 
KDEFrameworksBuildsystem, be considered a "KDE dependency". It would be very 
similar.

Beside that, none of the stuff in 
FindKDE4Internal.cmake/KDE4Macros.cmake/KDE4Defaults.cmake is actually 
_necessary_ to build software.
It "only" does two things:
* it makes developing for "KDE" more convenient, e.g. it presets RPATH 
settings, so developers have to care less
* it helps with consistency among stuff which uses them, like e.g. the install 
directories


Another issue with putting all small things into different places, e.g. some 
macros into e-c-m, some into kcore, some into kdocumentation, etc., is that 
the macros will all change their name.
Right now they all have the "KDE4_" prefix, because they come from 
FindKDE4Internal.cmake. And only stuff from that file uses this prefix.
If we distribute the macros, some will get the "ECM" prefix, some "KCORE", 
some "KDOC", etc.
If we expect that the future KDE application developers are aware where all 
the things come from exactly, then maybe it's no problem.
Or should they all be aliased on a FindKDEFrameworks5.cmake file ? I don't 
think I consider this a good solution.

I'd like to come to a conclusion with this still in January.

I think we agree that many/most of the various macros could go into the 
respective library packages.
What is left are all the settings we provide, install dirs, options, compiler 
flags and convenience/consistency macros like kde4_add_unit_test().
I think they should go together into one place.

Alex