I'm out

[Alexander Neundorf]

Hi,

until recently I thought I was still the maintainer of the buildsystem for 
KDE4 and also KF5, but I think the consensus on this list here is that Stephen 
has taken over this role.
So I'll let him do that, and stay out of the way.

I'll still have a look at KDE4 stuff, but for KF5 (including extra-cmake-
modules) I'll let you do what you want. Put me on CC directly if you have 
questions. Maybe I'll join again later, we'll see.

As I see it, Stephen and I disagree on a lot of fundamental things, and this 
makes working on KF5 anything but fun for me. Stephen went ahead and changed 
them all, and more or less all of them without proposal or discussion, at 
least I am not aware of those.
Also, I simply finally have enough of these discussions in my spare time.

Here's what I'm talking of:

- requiring versions of cmake. For me, I don't want to annoy developers, I 
want to decrease their work. I don't want that cmake is seen as a tool which 
all the time requires work. You know that from KDE4. We increased the required 
versions only rarely, everytime with a long warning period. I would keep it 
this way for KF5 too. Stephen decided to require bleeding edge cmake for KF5.

- releasing extra-cmake-modules.
Two years ago in Randa, people told me they would like to use cmake stuff from 
KDE also in non-KDE projects, including the wealth of Find-modules. So I would 
have preferred to have a release of extra-cmake-modules very early, last year 
if possible, including a bunch of useful macros and some Find-modules. Not 
complete, but in good shape. Those people who talked to me at Randa would have 
liked that, and all the developers who regularly ask on the cmake list or in 
the cmake bug tracker would have liked it and maybe they even would have 
contributed.
This was not possible, in my opinion mainly because Stephen added a bunch of 
preliminary files to extra-cmake-modules which were very much not releasable, 
API-wise, documentation-wise, and, as I said, only preliminary. We as of today 
have those files in e-c-m, and they block us from making a release.
Stephen wants to release e-c-m when KF5 gets released.

- imperative and explicit (some may say lengthy) vs. declarative and short 
(some may say magic). I want the cmake code to be easy to read and understand, 
i.e. explicit and maybe long, Stephen wants the cmake code to be a short as 
possible. IMO while this may make it easier to write, it makes it harder to 
understand and modify.

- using target names vs. variables. You know that. We'll have ALIAS targets.

- the cmake coding style. Not really a big issue for me, but it adds to the 
rest. The only place I am aware of where our cmake coding style is documented, 
is here: http://techbase.kde.org/Policies/CMake_Coding_Style , so that's the 
document to follow. If you want to, look at the history. At some point Stephen 
blamed me I wouldn't follow the correct coding style, according to him 2 
spaces and closing the function on a separate line. I don't know how he came 
to think this would be the cmake coding style.


Alex