Getting ecm files from the ECM package

Stephen Kelly steveire at gmail.com
Sun Nov 3 20:01:01 UTC 2013


Alexander Neundorf wrote:

> 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).

Yes, you can move it to that file if you like.

> 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.

It is the only guaranteed dependency of all the frameworks, so ECM has been 
the appropriate place to put temporary hacks, yes. A temporary hack is added 
when we discover a need for it. We also create a proper fix upstream.

Today, we are mostly past the point of needing new hacks. Thanks to the 
excellent splitting work that has gone on over the last months, we know 
better what we require from Qt and CMake, and we know that those things that 
we need are provided (except in a few cases). 

We have many known knowns, and a small number of known unknowns. I'm sure we 
still have unknown unknowns which will become known when more people try 
things out after splitting, but that's what a release cycle is for.

Thanks,

Steve.




More information about the Kde-frameworks-devel mailing list