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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
