Automatically setting the RPATH - make use of $ORIGIN ?

[Stephen Kelly]

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.