On Monday, November 02, 2015 04:08:55 PM Andreas Pakulat wrote:
> Hi,
>
> On Mon, Nov 2, 2015 at 2:49 PM, Boudewijn Rempt <boud@valdyas.org> wrote:
> > On Mon, 2 Nov 2015, Andreas Pakulat wrote:
> >
> > I think the idea of using @rpath as install name of the Qt libraries is
> >
> >> geared towards the usecase
> >> of shipping Qt within the application bundle of the application. In that
> >> case all you need is set
> >> the rpath @executable_path/../Frameworks or so in the executable and thus
> >> the app-bundle is
> >> relocatable. In order to get that with CMake you'll likely need to use
> >> the BundleUtilities, though
> >> its been so long since I used those I don't know if they can handle this
> >> scenario out of the box.
> >
> > Yes, that's what I'm trying to do -- well, I'm trying to do two
> > things. One is setup a build environment where kde apps like desktoptojson
> > can run, the other is creating a bundle, preferably using the same
> > Qt. I got quite far by manually fixing up the applications built as part
> > of kcoreaddons
>
> That would be fixed in kcoreaddons by extending the linker flags to include
> the mentioned -Wl,-rpath,<qtlibdir>. There's no provisioning for this
> inside CMake afaik since its hard for it to guess what the intention is.

CMake does automatically handle this.  If a library being linked has @rpath
for its install ID, then CMake will insert the linker flag.  This takes care of
the build time rpath.  And works for any library in target_link_libraries()
where CMake knows its full path.  A -L/-l approach does not work, but that is
usually done for system libraries, in which case we normally don't care about
rpaths.

This kind of thing isn't handled automatically at install time, and requires
the INSTALL_RPATH property to be set.