> 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
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
