Getting ecm files from the ECM package

[Alexander Neundorf]

On Sunday 03 November 2013, Sune Vuorela wrote:
> On 2013-11-03, Alexander Neundorf <neundorf at kde.org> wrote:
> > This code unconditionally searches for QtCore (and sets a target property
> > where I'm not sure how many people here can understand what's going on).
> 
> It is hopefully a temporary hack that shouldn't be in that file.
> 
> Sometimes, temporary hacks in development stuff is unfortunately needed,
> but I do hope that whoever introduced it has a plan to get it out.
> 
> I agree that finding ECM should just be finding ECM and not requiring a
> Qt install.
> 
> It is though okay to have something bits in ECM that has a hard
> dependency on Qt - maybe a ecm_do_extreme_magic_with_qt_resource_files
> could be a theoretical thing that could be in ECM and require Qt to be
> found to be useful for anything.

Yes, sure. If there is a Qt-related macro this should of course do something 
with Qt.

Sometimes temporary hacks may be necessary.
This code in that file is not necessary (e.g. KDECompilerSettings.cmake would 
be much more approriate, because if this file is used, you most probably want 
to use Qt).
My problem is that ECM has been handled like this by Stephen from the 
beginning.
I wanted to release ECM as fast as possible, since this was one of the main 
points I got from the platform meeting in Randa in June 2011: people want to 
be able to use cmake stuff from KDE without depending on kdelibs.
Stephen added files, partly without documentation, partly with strange 
interfaces, partly with temporary hacks. Together this has the effect that 
since 2 years ECM is continously not in a releasable state.
To me this is very frustrating, because this was the goal why I created the 
ECM repository at all.
I wanted to establish ECM as THE source for additional cmake stuff, with 
contributions not only from KDE, but from other developers too. This is now 
impossible for more than 2 years already, since we were not able to release 
it. Still today the plan is to release it even later than the first frameworks 
libraries.
Me and Stephen talked about this last year, and I accepted Stephens plan not 
to release early, since he is doing so much of the work.
There have been several other attempts to create packages which bundle custom 
cmake find-modules, but none of them became really popular. ECM would have had 
the chance to succeed because it would have had a head start given the big 
number of find-modules we have in kdelibs.
But if it is continously treated like this, i.e. whatever is needed to fix 
something in KF5 is just committed there, this cannot work.

By splitting the "ECM" library into two "libraries", one geared towards KF5, 
and one containing general useful stuff, this issue would be solved.
General useful stuff would go into ECM, and it would only be accepted if it is 
in releasable state, and this would be released e.g. once per month.
Hacks needed to make something work in KF5 would go into the other (KF5 tier0) 
package.

I did not complain too much about Stephens commits since he is doing great 
work in general, contributing so much more and spending so much more time on 
KF5 than I do.

Alex