On Aug 13, 2014, at 11:07 AM, Oswald Buddenhagen <[email protected]> wrote:
> On Tue, Aug 12, 2014 at 07:08:45PM -0400, Jake Petroules wrote: >> On 2014-08-12, at 06:50 PM, Adam Strzelecki <[email protected]> wrote: >>> 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. >>> > yes. except that i want these to be called QMAKE_BUNDLE_*. > this is irrespective of x-platform use. i like the idea of calling the > functionality "bundling". > >>>> (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. >>> > i'm not so sure about the details. > the thing is that the .dst specification is way too "precise", thus > making x-platform use impossible. even the existing QMAKE_BUNDLE_FILES > isn't that precise (which enables supporting ios and osx bundles without > changes to the project ... provided somebody bothers to polish up the > qmake changes that are supposed to make this actually work). > >>>> (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 don't understand what this has to do with qbs Export {}. > >>>> (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. >> > i'm kind of losing at least one of you guys here. > it's beyond obvious that existing projects *will* need at least one > modification: CONFIG += bundle_qt (and possibly additional > QMAKE_BUNDLE_* for non-qt dependencies). there is no way i'd allow > a major behavior change like making this the default. > and when these options are enabled, it seems pretty much a no-brainer > that qmake would also automatically add the right rpaths to make these > bundled dependencies actually useful. why would you ever *not* do that? Afaics the suggestion is to never have the absolute path to the Qt frameworks added to the rpath at all. Which would make the rpaths *only* be useful for the bundled dependencies. So, when not using the “bundle stuff” option, it would require setting either DYLD_.... in the run environment, or explicitly adding the absolute Qt path to your binaries’ rpath, to be able to run the result. I still do not see why the absolute path shouldn’t be added when _not_ bundling Qt though. -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
