Alexander Neundorf wrote: >> Assuming you mean the first option, why would it make us require new >> versions of cmake often? > > With the kde4_add_executable() etc. macros we were able to add things > there, while keeping the required minimum cmake version. Without those > macros, either the developer has to do it manually, or we have to upstream > it into cmake, and then require the new version (in cases where it's > necessary for producing a working result, which is not the case with RPATH > here).
I don't really understand your position here to be honest. Presumably, we'll test the feature and make sure it works, and start with a working result for many cases or our testable cases. Then at a high level, we'll always go from a working result to a result which works better. If an edge-case is then discovered on some platform, that doesn't mean we have to bump the minimum 'globally', but it means that on that platform, they'll have to use the newest version. Eg, imagine we depended on CMake 2.8.9 and used the POSITION_INDEPENDENT_CODE feature. Then on some platform, the feature was broken in CMake (eg http://public.kitware.com/Bug/view.php?id=13932, but pretend it wasn't Fortran specific :) ), and fixed in CMake 2.8.11. Do we have to globally bump our minimum requirement to 2.8.11? I'd say no, but that guy has to bump *his* requirement to 2.8.11. Because the feature is in CMake and not in KDE, for KDE to bump its version requirement doesn't help him if he's using anything 'non-KDE' which also expects the PIC feature to work. He'll need the new cmake version anyway, and it's not really KDEs place to tell him that IMO. In most cases we care about the available cmake version is determined by the distro. Imagine that there was a bug in cmake 2.8.9, and fixed in 2.8.11, that affected freebsd. That problem is fixed by freebsd shipping 2.8.11. In the end, we need to expect features in cmake to work, and in cases where they do not work, we need to expect them to be fixed. We can reasonably test features, then expect them to work, and after that it's none of KDEs business if cmake has bugs in areas we did not test. It's a bug in cmake. I wouldn't object to putting helpful messages such as if (FREEBSD AND CMAKE_VERSION VERSION_LESS 2.8.11) message(FATAL_ERROR "Due to cmake bug #12345 cmake 2.8.11 is needed on this platform") endif() in our code. That wouldn't bring inconveniences of requiring a cmake version released within the last two months or whatever on everybody. Eventually, we'll bump the cmake version requirement anyway and can remove it. If a more-serious non-working case is discovered, then yes, we may have to globally bump the minimum requirement. However, that is true of every feature of cmake and every feature of Qt. So, I don't see any reason to single out RPATH handling for special treatment compared to anything else, such as the PIC feature. All we need to do is ensure that the feature works, in principle at least, on platforms we care about. A unit test and the cmake dashboard already takes care of that. Thanks, Steve. _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
