Alexander Neundorf wrote: > On Sunday 03 November 2013, Sune Vuorela wrote: >> On 2013-11-03, Alexander Neundorf <neund...@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. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
