On Fri, Aug 01, 2014 at 02:24:03PM -0400, Jake Petroules wrote: > What might be good, too, is a QMAKE_EMBEDDED_FRAMEWORKS or somesuch > which copies the Qt frameworks into the application bundle at build > time (though you'd still set DYLD_LIBRARY_PATH because not everyone > would necessarily use QMAKE_EMBEDDED_FRAMEWORKS). No reason to > postpone that step to macdeployqt; this is how the native Apple tools > work anyways.
> Ossi will disagree with me here and say that anything to do with > creating bundle structures is a deployment step only, though. :) > of course, but that has no bearing to qmake, as it does in-place deployment anyway (cf. QMAKE_BUNDLE_FILES. which means that your variable would be called QMAKE_BUNDLE_FRAMEWORKS, and would actually just be a convenience wrapper around the former). also, qmake has a deploy step: "install". but as-is, it is mostly meaningless for bundle builds. also, in some other thread (or a jira task or review) i stipulated that *deployqt should be backends of qmake anyway, fully controlled by variables defined within the project (and the make invocation). that would make the question where the step belongs meaningless. and as you know, in the qbs context i insist that dependencies must be declared exclusively via the Depends item (and not ever any compiler and linker flags), for which one of the reasons is allowing the tool to make sensible deployment decisions depending on the target and build type. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
