<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 2, 2015 at 4:26 PM, Clinton Stimpson <span dir="ltr"><<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Monday, November 02, 2015 04:08:55 PM Andreas Pakulat wrote:<br>
> Hi,<br>
><br>
> On Mon, Nov 2, 2015 at 2:49 PM, Boudewijn Rempt <<a href="mailto:boud@valdyas.org">boud@valdyas.org</a>> wrote:<br>
> > On Mon, 2 Nov 2015, Andreas Pakulat wrote:<br>
> ><br>
> > I think the idea of using @rpath as install name of the Qt libraries is<br>
> ><br>
> >> geared towards the usecase<br>
> >> of shipping Qt within the application bundle of the application. In that<br>
> >> case all you need is set<br>
> >> the rpath @executable_path/../Frameworks or so in the executable and thus<br>
> >> the app-bundle is<br>
> >> relocatable. In order to get that with CMake you'll likely need to use<br>
> >> the BundleUtilities, though<br>
> >> its been so long since I used those I don't know if they can handle this<br>
> >> scenario out of the box.<br>
> ><br>
> > Yes, that's what I'm trying to do -- well, I'm trying to do two<br>
> > things. One is setup a build environment where kde apps like desktoptojson<br>
> > can run, the other is creating a bundle, preferably using the same<br>
> > Qt. I got quite far by manually fixing up the applications built as part<br>
> > of kcoreaddons<br>
><br>
> That would be fixed in kcoreaddons by extending the linker flags to include<br>
> the mentioned -Wl,-rpath,<qtlibdir>. There's no provisioning for this<br>
> inside CMake afaik since its hard for it to guess what the intention is.<br>
<br>
</span>CMake does automatically handle this.  If a library being linked has @rpath<br>
for its install ID, then CMake will insert the linker flag.  This takes care of<br>
the build time rpath.  And works for any library in target_link_libraries()<br>
where CMake knows its full path.  A -L/-l approach does not work, but that is<br>
usually done for system libraries, in which case we normally don't care about<br>
rpaths.<br>
<br>
This kind of thing isn't handled automatically at install time, and requires<br>
the INSTALL_RPATH property to be set.</blockquote><div><br></div><div>Thanks for correcting me - didn't see your first mail until now either. It seems I'm really out of touch with CMake these days :)</div><div><br></div><div>So I guess KDE frameworks that generate development-tools lack the INSTALL_RPATH - at least that would explain the necessity to manually patch them. A relative path like you mentioned should work as long as Qt is installed in the same prefix as those tools - which is likely the common case.</div><div><br></div><div>An end-user application then can either decide to be installed in the same way or it wants an app-bundle, then it could use an INSTALL_RPATH like @executable/../Frameworks and bunlde the Qt frameworks inside that subdirectory.</div><div><br></div><div>Andreas</div></div></div></div>