Having a Tier 0 for cmake and git submodules

[Alexander Neundorf]

On Sunday 10 November 2013, Kevin Ottens wrote:
> Hello,
> 
> Since there's been several times discussions about having a kind of "Tier
> 0" for building our frameworks containing what is right now in ECM
> kde-modules directory, but the idea was never really on the table because
> of the extra dependency it'd bring, I looked a bit at the git submodule
> option to get there.
> 
> The motivation for going with a git submodule is that it would allow such a
> Tier 0 to be completely transparent to third parties who would want to grab
> a Tier 1 framework and not bother about installing anything else than our
> main dependencies (namely Qt, CMake and ECM).
> 
> Again: If we force third parties to install another KDE specific dependency
> to build a Tier 1 framework from sources we failed.
> 
> So after playing a bit with several solutions (I looked at git subtree too
> for instance), I still think that git submodule is the solution to use if
> we got for such a Tier 0... it's not perfect though.
> 
> Indeed, submodules keep the information of the exact sha-1 used, there's no
> way to have them track a branch automatically. That's likely to turn into a
> problem (not for third parties this time but for our own developers) as
> from the master branch of a framework we probably always want the tipping
> point of the master branch of the repository containing the cmake files.
> 
> Also git archive ignores submodules when generating the archive... But
> that's easy to fix and there's a git archive-all script available which
> does the recursive export.
> 
> Now back to the submodules sha-1 update... The only thing I see to easily
> overcome that for our developers, is to have a hook, which would update the
> submodules for all the frameworks every time someone pushes in the tier 0
> repository. Is it something the sysadmins would agree to have on the
> server?
> 
> Any opinions or thoughts on that?
> 
> If we agree on the approach I think we have a potential solution for
> injecting a tier 0 in all our frameworks that could be put into place when
> we start splitting the repositories.

just one more thing which I just became more aware of, and because there seems 
to be quite some opposition to two build-system related packages...


Let's say you want to use two or more KF5 libs, e.g. KArchive, KConfig and 
Solid, from some application. Let's also assume that you use the (development) 
packages of these libraries coming with the distribution (or maybe some binary 
packages on Windows).
What options do you have and which dependencies do you get ?


You can do

1.)
find_package(KArchive)
find_package(Solid)
find_package(KConfig)
and everything is fine. You get the libs and include dirs for the three 
packages, each of them found somewhere on the system, and that's it.
Neither ECM nor kf5umbrella nor tier0 required.

Until recently, ECM had FindKF5.cmake, which made it possible to load multiple 
KF5 libs using one command, with the additional feature that it would prefer 
libraries from a common install prefix (which probably belong to one 
frameworks build).
So you could do:

2.)
find_package(ECM)
find_package(KF5 COMPONENTS Solid KArchive KConfig)

This way, additionally to Solid, KConfig and Archive, the ECM package was 
required.

Another feature was that it gave you a terse way to get the normal KDE cmake 
environment, consisting of the install dir variables, a bunch of cmake 
settings like e.g. rpath handling, and compiler flags for the different 
platforms and compilers supported by KDE via 3 "virtual" components:

3.)
find_package(ECM)
find_package(KF5 COMPONENTS InstallDirs CMake Compiler Solid KArchive KConfig)

Still, additionally to Solid, KConfig and KArchive, "only" ECM was required.


Now FindKF5.cmake has been removed from ECM and a tier1/kf5umbrella has been 
added, which installs a KF5Config.cmake. This is in general the correct thing 
to do.
To get the full KDE cmake environment, which I guess most KDE SC applications 
(building on top of frameworks) want, you now need to do either:

4.)
find_package(KArchive)
find_package(Solid)
find_package(KConfig)
find_package(ECM)
include(KDECMakeSettings)
include(KDEInstallDirs)
include(KDECompilerSettings)

or, if you want to use the kf5umbrella:

5.)
find_package(KF5 COMPONENTS Solid KArchive KConfig)
find_package(ECM)
include(KDECMakeSettings)
include(KDEInstallDirs)
include(KDECompilerSettings)

i.e. to use frameworks this way, two additional packages are required right 
now, ECM and tier1/kf5umbrella/.
I assume everybody here is aware of that ?


If KDECMakeSettings.cmake, KDEInstallDirs.cmake and KDECompilerSettings.cmake 
were part of the kf5umbrella/, it would look like this:

6.)
find_package(KF5 COMPONENTS Solid KArchive KConfig)
include(KDECMakeSettings)
include(KDEInstallDirs)
include(KDECompilerSettings)

Only tier1/kf5umbrella/ would be required to get the full KDE cmake 
environment.
ECM would then only be required if anything from it is actually needed, case 
by case.


IMO, usage 1.) is what "3rd party users" of our frameworks will do.
What usage is recommended for application or KDE SC developers ?


Alex

P.S. What all libraries in frameworks currently use from ECM is a macro for 
generating version headers. This is in general not needed for applications. 
Additionally, a macro which helps with setting up tests.
It's nice to have, but you can build applications without it. Both macros are 
mainly there to make maintaining the big number of separate libraries in KF5 
easier. For smaller projects, where there is a maintainer for each library, 
this is not much of an issue. So ECM is still useful there, but not a 
mandatory requirement.