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

[Adam Strzelecki]

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

> Also, believe it or not, but I agree with not copying frameworks by default (see below)...

Okay. From me it simply does not matter as long it can be turned on/off with simple switch like CONFIG -= .... I just said I don't want start again discussion about performance, speed, etc. etc. I am sorry if that has sounded rude.

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

> Yes, cp is a very slow way of copying, and is especially intolerable for incremental builds. Using rsync is much better as you get instantaneous (< 70ms) incremental builds (and makes your speed argument about making copying non-default, totally pointless).

I explicitly wrote this is just sketch, a rough example, not actual implementation. So please don't bash me for mentioning "cp".

> So, this is all wrong; the biggest problem is that it's too Qt centric.

That's not the point. Point is that if we change something it should work for Qt apps out of the box, w/o any need to change existing projects. Unless these changes gonna land in some major release i.e. Qt 6.

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

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

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

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

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

> 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