[Development] Qt 4.x and Qt 5 frameworks should use @rpath (QTBUG-31814)

[Jake Petroules]

On 2014-08-12, at 06:50 PM, Adam Strzelecki <ono at java.pl> wrote:

>> Please stop saying that to fuel your argument just because I disagree with some of your points; it sounds kind of rude. Also, I am one of these "stakeholders", though I'm not sure what definition you're going off of, because the dictionary's definition "a person with an interest or concern in something" would include you as well, now, wouldn't it? ;)
> 
> Well this is generic definition, but from perspective of project management "stakeholder" is someone going to be (maybe seriously) affected by the changes. Maybe I assumed incorrectly that you are not running some commercial or OSS projects based on Qt. Do you?

Yes.

>> This falls apart in the face of third party libraries. Who says a particular application is even using Qt with qmake?
> 
> Nobody. But give me some real example of project using qmake but not using Qt.

People do it. Anyways, moot, as you appear to mostly agree with the alternate proposed solution which handles this case as well.

>> Also, it's extremely inflexible (as is macdeployqt). In the real world, people use more libraries than just Qt and may want to customize their bundle layout, the locations of embedded frameworks, etc. So let's summarize what must be done:
> 
> I agree that such facility should be provided internally while implementing Phase II changes.
> 
>> (1) Add qmake options QMAKE_EMBEDDED_FRAMEWORKS, QMAKE_EMBEDDED_LIBRARIES, QMAKE_EMBEDDED_PLUGINS, each taking a list of absolute paths and/or objects; applies to any qmake bundle target, app, framework, etc. Does nothing for non-bundle targets. Does nothing outside of OS X and iOS.
> 
> Makes sense.
> 
>> (1a) "objects" (don't know what this is called in qmake but INSTALLS works similarly) meaning:
>> 
>> weirdlib.src = /Library/Frameworks/WeirdLib.framework
>> weirdlib.dst = $$join($$QMAKE_EMBEDDED_FRAMEWORKS_LOCATION, SubFolderForSomeReason)
>> weirdlib.headers = true
>> weirdlib.variants = debug release
>> QMAKE_EMBEDDED_FRAMEWORKS += weirdlib /Library/Frameworks/Sparkle.framework
> 
> Thumbs up. Good idea.
> 
>> (4) User's OWN responsibility (NOT qmake's) to set QMAKE_RPATHDIR for their application/library/framework to whatever they like - @executable_path/../Frameworks, $$[QT_INSTALL_LIBS], /Library/Application Support/FooBar/Frameworks, etc.
> 
> I disagree here. This should work out of the box for any simple or existing Qt app, regardless what Qt modules it uses. Requiring changes to existing projects is bad idea.

I disagree that it's a bad idea, but putting on my qbs hat for a moment and thinking about Export { } I'm willing to concede here. I suppose it would be fine to default to @executable_path/../Frameworks  - as long as the user can override this to an empty list (note that "empty list" and "undefined" are not the same, i.e. `QMAKE_RPATHDIR = ` MUST result in an empty rpath list).

>> (1) NO changes are made to USER targets by qmake, ever. That means qmake MUST NOT set any rpaths in user targets unless EXPLICITLY given by the user with QMAKE_RPATHDIR (currently you are doing this but only as a transitionary measure and it will be removed once support for copying frameworks is added).
> 
> Correct me if I am wrong, but changes are needed to all existing projects or/and user environment (DYLD_...), otherwise their freshly built app won't start and we get plenty of post "why may app no longer starts with new Qt release".

Use the QT qmake variable to determine what frameworks to copy by default and you don't have this problem.

>> Now, if some people don't like the standard way of doing things... scenario: user doesn't want to copy frameworks (note that your no-default-copy idea falls apart for third party libraries so you'd need to end up adding additional rpaths to your app ANYWAYS):
>> 
>> <code>
>> CONFIG(debug, debug|release) {
>>   QMAKE_EMBEDDED_FRAMEWORKS =  # empty
>>   QMAKE_RPATHDIR = $$[QT_INSTALL_LIBS]
>> }
>> <code>
> 
> So what's the tradeoff here? Forcing changes to existing (possible abandoned, non-maintained anymore) projects in favor of not running install_name_tool on bundle step?

Use the QT qmake variable to determine what frameworks to copy by default and you don't have this problem. I'm just saying, if you're a performance pedant, you have this option. Options are good.

The goal is to not HAVE a "bundle step" at all. Fully integrated.

>> (1) No need for `install_name_tool -delete_rpath` when you want to release.
> 
> Frankly I completely don't get your arguments that install_name_tool -delete_rpath is evil. Anyway in most of the cases you will require to codesign the executable within the bundle, which does also modify macho-o.

The reason is: the bundle is not relocatable. And there's no point in adding a $$[QT_INSTALL_LIBS] rpath in the first place. See above.

>> (2) Doesn't bother anyone else or engineer qmake completely for one single non-standard use case (i.e. yours).
> 
> But does bother everyone using standard use cases.

Err, what? Standard use case is @rpath + copy frameworks. So if that's done by default, and macdeployqt is deleted, no one is bothered.

>> Discuss. Keep in mind that I am very much in favour of solutions that will serve all parties' use cases. Flexibility here is key.
> 
> As long as it does not impact majority of existing users & projects.
> 
> --Adam

-- 
Jake Petroules - jake.petroules at petroules.com
Chief Technology Officer - Petroules Corporation