Automatically setting the RPATH - make use of $ORIGIN ?

[Alexander Neundorf]

On Saturday 23 February 2013, Stephen Kelly wrote:
> 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.

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

If we know that, we need to make sure that (at least) on FreeBSD this version 
is used.
Either via the required version, or as you show below.

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, or worse complain 
in public how cmake sucks.

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

As I said, e.g. the RPATH handling here would not be a reason to require the 
newer version.
Users with the older version would simply not get that feature.

Maybe it's indeed good enough to error out as you do above on a per-platform 
basis.
This would have been good enough e.g. also for the Windows-manifest feature.
Setting the link interface to empty by default was possible to do inside these 
macros.
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.

Alex