Getting ecm files from the ECM package

[Alexander Neundorf]

On Thursday 31 October 2013, David Faure wrote:
> On Thursday 31 October 2013 17:54:06 Alexander Neundorf wrote:
> > IOW, those three files exist only for KF5, and no other reason.
> 
> This contradicts "use KDECMakeSettings.cmake in gammaray if you want
> automatic RPATH handling" as you told me some time ago.
> 
> In other words, these things are convenience on top of cmake, not only
> useful for KF5.


Let me explain how I see things.
Up to KDE4, things were simple.
There was the kdelibs module. It was released together, dependencies within it 
were ok, it was hosted on KDE infrastructure and developed by KDE people.
Software using that used "KDE".

With frameworks things are becoming in my view very different.
Every library will be in a separate repository.
What makes e.g. karchive a KF5 tier1 library and not just some library using 
Qt, like e.g. Qwt ?
There is no clear *technical* difference.
There are let's say organizational differences: it is hosted on KDE servers, 
it is developed by people with KDE accounts, it is (not quite sure about this) 
released together with a whole bunch of other libraries, it follows KDE best 
practices and it has the stamp "KF5" on it, given by people with KDE accounts.
So, as you say that e.g. KDECMakeSettings.cmake can be used also by "non-KF5" 
software, the same is true for every tier1 library. We could ask for a lot if 
not all tier1 libraries why aren't they upstreamed into Qt ?


What does e-c-m contain today: a bunch of find-modules and generic macros, 
which are useful for some packages, wether they use Qt or not.
Additionally, KDEInstallDirs.cmake, KDECMakeSettings.cmake and 
KDECompilerSettings.cmake.
As a fact, all KF5 frameworks on these three files, including the tier1 libs.
All KF5 software could technically also be compiled and linked without these 
three files.
So why does everything use them ?
They are used to follow "KDE best practices".

KDEInstallDirs.cmake is used to provide a common and complete set of install 
location variables, to make sure KDE developers find a common cmake 
environment when looking at other KDE projects. Projects which don't have the 
requirement that it should be easy for KDE developers to work on them have no 
need to use this file. They can use GNUInstallDirs.cmake, or even hardcode 
install locations. This would not be ok for KDE software, since we have 
requirements for portability etc., but it may be ok for other projects.

The same for KDECompilerSettings.cmake. It is used to make KDE software build 
in all platforms KDE supports, with the compiler features needed by KDE.

KDECMakeSettings.cmake is there to provide a set of cmake settings, again to 
give KDE developers a common setup where they don't have to care much about 
other things themselves.

So all three files are there for the convenience of KDE developers, to make 
the projects follow KDE requirements and best practices, and their content is 
governed by what is considered useful by KDE developers for KDE (e.g. at work 
we need different RPATH settings).


So here's my ideal view of the world, which clashes with the rule that there 
must not be a tier0:

Upstream: Qt and CMake

ECM: hosted somewhere, e.g. on github, contains find-modules and generic 
macros, not only KDE-developers contribute, it is released frequently, e.g. 
monthly. Required by packages which need some of the contained files, i.e. not 
necessarily used by all KF5 or all KDE packages, but OTOH used also by non-KDE 
and non-Qt packages. [1]

[For the packages below, development is governed exclusively by KDE 
developers, which is not the case for the packages above.]

tier0: kf5-build-files (or some name): Stephens KF5Config.cmake, additionally 
containing the three KDE*.cmake files mentioned above. Hosted by KDE. All KF5 
packages, including tier1, depend on it for building. Released coordinated 
with the rest of KF5.
So I agree with Stephen that it is the correct thing to have the KF5 umbrella 
cmake file in a separate package. But I would have made that tier0.

tier1, 2, 3: they all depend at buildtime on tier0. Beside that, everything as 
we know it.


To get back to Gammaray: with this view, there is no contradiction. By using 
KDECMakeSettings.cmake, Gammaray would simply be a user of the tier0 KF5 
framework.

Alex


[1] Why not merge that into CMake ? For quicker releases, and even easier 
contributing. Also Bill once said that in hindsight he would have prefered if 
cmake would not ship any find-modules itself at all. So one could imagine that 
cmake would come without any find-modules in the future, and all find-modules 
would come from a separate package, e.g. ECM.
This would make cmake the core tool, and ECM its "standard library".