I'm out

[Alexander Neundorf]

On Thursday 22 August 2013, Kevin Ottens wrote:
> Hello,
> 
> On Thursday 22 August 2013 09:14:16 Stephen Kelly wrote:
> > Mark wrote:
> > > On Wed, Aug 21, 2013 at 10:20 PM, Alexander Neundorf <neundorf at kde.org>
> > > 
> > > wrote:
> > >> 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.
> > > 
> > > Hi Alexander,
> > > 
> > > I'm sorry to hear that! I hope you keep sticking around in KDE :)
> > > As for the issues, why don't you and Stephen just find yourself a
> > > quiet place on IRC and talk about it?
> > 
> > I agree with everything Mark wrote. I hope you stick around and I think a
> > chat on IRC would be useful.
> 
> Likewise, it's been a while that I try to push you two to discuss more. I

I don't like blaming people, but I don't think I behaved that badly...

I didn't simply commit stuff which would go against what had been already 
committed, instead in such cases I always started a discussion, when I thought 
I would step on somebody else's toes otherwise.
Which of course was then often an "against something" discussion, since the 
code had already been committed (without prior discussion).

I am still surprised how my previous maintainer role has been ignored here on 
the list. I'm not used to that from KDE.
My impression is that Stephen just commits and everything is fine, and if I 
try to start a discussion, in the hope to come to an agreement with Stephen, I 
suddenly have to defend my position e.g. against you, although you are not 
even working on the buildsystem. This doesn't feel like I still got trust 
here.
I know I was somewhat late to join here early last year, since I thought due 
to the missing export-depending-targets-into-multiple-export-sets feature in 
cmake not much can be already done in kdelibs on the buildsystem, but I was 
wrong with that.
Since then I was continously (minus vacations and business trips) working for 
KDE frameworks (which sometimes also meant working on cmake or reviewing 
patches for Qt). And which also means just a few hours in the evenings.

As I see it, there were not many things really missing in cmake, in order to 
be ready for KF5. This was a working automoc, a few modules, and the ability 
to export dependent targets from one project into multiple separate export 
sets. These were features for which we needed a new cmake version, and which 
IMO justify annoying developers with upgrades. I added them to cmake. Since 
then, probably a year ago or so, we could have had a stable buildsystem.

Much of the new target features, which make working with exporting/importing 
targets much nicer, were not required to make KF5 possible. They are really 
nice and elegant, no doubt, but IMO they did not justify to require developers 
to update cmake, build cmake from git master, etc.
It could have been great e.g. if Stephen would have discussed with me 
beforehand what he plans to do with the targets in cmake, and maybe I could 
have integrated it in KDE, so he would have gotten feedback. It didn't work 
that way, partly also because I do not have that much time to follow Stephens 
speed. I wasn't even able to follow all the discussions on cmake-devel between 
Stephen and Brad on these topics. If I had done that, this would have consumed 
all of my time.

The problems we had with building Qt for several weeks also didn't help.


You know, my main goal here was not to tweak our buildsystem so that the KDE 
frameworks developers can progress as fast as possible.
What we do in KDE with cmake serves as example for others how cmake can/should 
be used, and I care about that. From here many developers carry it into other 
projects or their working places, and other developers look what we are doing.
So my main goal was to set a good example how things should be done with CMake 
in general.

I had big plans for extra-cmake-modules.
People complain that the result from find_package() is not standardized.
Results are ALL_UPPER_CASE, or ExactCase, or _LIBS or _LIBRARIES.
In kdelibs4 we mostly used ALL_UPPER_CASE, because this seemed to me what the 
majority of Find-modules coming with cmake in 2007, did, and this is how I 
interpreted readme.txt in cmake, where unfortunately the example was named 
"FindXXX.cmake", so ALL_UPPER_CASE and ExactCase look identical.
Anyway, Stephen and others convinced me that ExactCase is the way to go, so I 
made that clear in the readme.txt.

So my plan was to provide with extra-cmake-modules a collection of Find-
modules which all nicely follow that standard, so that users can simply do

find_package(Foo)
and use ${Foo_LIBRARIES} and ${Foo_INCLUDE_DIRS}.
So that there will be consistency.

Using the standard Foo_LIBRARIES was rejected here.

I proposed Foo_LIBRARY_TARGETS  here, which would still have the advantage of 
a standard naming, and some added guarantees.
It was also rejected.

So now we'll use names like KF5::KCoreAddons directly.

For me, my hope for consistency in the results of find_package() is gone with 
this.
On the internet (people do google for Find-modules) there are now a whole 
bunch of find-modules which use ${ALL_UPPER_CASE_LIBRARIES}, there is a whole 
bunch of find-module and Config-files which use ${ExactCase_LIBRARIES}, and 
there will be a whole bunch of Config-files which use target names, without a 
simple direct rule how those target names relate to the package name 
(KCoreAddons -> KF5::KCoreAddons, while close, still requires looking at 
documentation, others may not use a namespace, how should the namespace relate 
to the package name, etc. ?)

So what I now see in the future is a mixture of Find-modules and Config files 
providing their results in different ways, instead of a bunch of old Find-
modules still providing their results mostly in ${UPPERCASE_LIBRARIES}, while 
more or less all the new stuff providing their results in 
${ExactCase_LIBRARIES}.
May sound trivial, but it's a big thing for me, many users have complained 
about that, and I understand that.

If you think I'm somehow against using imported targets, you're wrong. I took 
part in the initial design discussion in 2007, I added imported targets to 
FindQt4.cmake 3 or 4 years ago or so, and also to kdelibs. Maybe most of you 
didn't notice that, and that's good; I tried to do it in a way that this 
didn't cause any disruption, nor that developers were forced to learn about 
that (if they didn't want to).


Another nice thing of a standard variable would have been that those packages 
could be made more easy available to non-cmake buildsystems.
Two years ago after Randa I added an option --find-package JPEG to cmake, so 
you can call cmake from the command line, it will search the given package, 
and print the link or compile arguments to stdout, so they can simply be used 
in a hand-written makefile or with autoconf etc.
This turned out to work not really well, due to the non-conformity of the 
results of find_package().
I was hoping that now with KDE frameworks we would produce a relatively big 
number of Config-files which would all set the standard _LIBRARIES and 
_INCLUDE_DIRS variables, and that by restricting the --find-package mode of 
cmake to work only on Config-files, I could get much better results, so that 
this would actually get real-world usable. I didn't start to work on this yet, 
but it seems reasonable to me. Now, if we simply use the imported targets 
directly, I can forget about that too.


I was hoping to attract non-KDE developers to contribute to extra-cmake-
modules. But without a release, this does not happen.
There are concerns like what to do if you want to use only one of the files 
coming with e-c-m, or only if you have a special version of cmake, so that in 
those case simply adding a module directory to CMAKE_MODULE_PATH wouldn't 
suffice. e-c-m can handle all that, and it is documented. But these are, it 
seems, issues which are of no concern here.
Also I'd like to require not always the latest version of cmake in e-c-m, but 
with that again I have bad chances here.
There are other places, and if we are aiming at users of KDE frameworks 
outside of KDE and maybe outside of FLOSS, where such things are problematic. 
At work, earlier this year, I increased the required cmake version of some 
small project to... was it 2.8.9, or 2.8.6 ? I don't remember exactly. I had 
to revert that after a few weeks back down to 2.8 or even 2.6.4 I think, 
because on some systems there simply was no newer cmake available, and users 
should not install their own packages on these systems. Until recently we had 
to support customers running RHEL4. I don't think I'm alone with that.
IMO e-c-m won't be very attractive to 3rd party developers if we continously 
require the latest cmake or even rc's.


I don't think it makes sense to have two maintainers which go into 
perpendicular directions (note that I don't say opposite directions).
My feeling is that Stephen has more backing here. He also seems to have much 
more time available.

Alex