Alexander Neundorf wrote: > I don't want to risk having people use a known non-working (in some > regard) version of cmake, and then come to the mailing list and ask,
Yes, I'm sure we'll have some solution between minimum_required and other version checks. > or worse complain in public how cmake sucks. This is not KDEs problem. * KDE has enough of its own trolls to take care of without taking on responsibility for complaints of upstream software. * People already complain publically that CMake sucks :). People also complain publically that Qt sucks. That is also not KDEs problem. * Such complaints are very unlikely. 'Mainstream' platforms won't fail due to cmake bugs in ways that would motivate anyone to publish a magazine article about how much cmake sucks. Such platforms are well covered by the cmake dashboard and kde developers themselves using it. Non-Mainstream platforms don't have the kind of trolls that the mainstream platforms have. * Such complaints are not a problem 'by definition', but only on a case by case basis. Even then, it's not KDEs problem :). So, I think we can safely not take responsibility for complaints about CMake upstream issues. CMake is big enough and old enough to take care of itself :). > Without remembering a specific case, from time to time there were issues > or wishes how something should be done. Having this layer (the macros) in > between the KDE developers and cmake, it is possible to adjust such things > inside these macros, without the need to get support for that specific > thing into cmake. I can see how that can have been convenient. That doesn't make it the best approach though, particularly in the long term, for several reasons (eg, KDE behavior diverging from 'normal' CMake behavior, CMake not getting features it should have such as the MinGW manifest stuff or the empty link interface stuff). I'm also not convinced that it's better to require the newest kdelibs than the newest CMake. Some KDE extragear software still has a minimum kdelibs requirement of 4.3. Considering how much easier it is to install a newer CMake, that should be the chosen approach. All this is just a sideline discussion though :). I do think that KDE should rely on RPATH features in CMake. Thanks, Steve. _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
