On Aug 12, 2014, at 4:25 PM, Adam Strzelecki <[email protected]> wrote: > Okay, Phase II. > > (1) Introduce "bundle_frameworks" CONFIG option, and set it default for > "rpath" shared builds on iOS & OS X
Can we please already now turn a cross-platform hat on, and at least think about options that at least do not right away block using the same for non-OS X? We already have/had the mess with DEPLOYMENT/INSTALLS with desktop/meego/symbian, I don’t want us ending up with the same again... (https://qt.gitorious.org/qt-creator/qt-creator/source/9471d96e572c527bf85a2ca82ebd49bbf6f3c162:share/qtcreator/templates/shared/deployment.pri) I do not see any reason why one shouldn’t be able to turn on copying Qt libs next to the application binary on Windows even without any changes on how Qt is built there. And usage of $ORIGIN on Linux doesn’t sound like a too bad idea to me either. “bundle_frameworks” already disqualifies using the same config option on anything non-OS X. (Aside from that, what is with dylib builds of Qt?) > (2) Introduce "bundle" make target, when "bundle_frameworks" CONFIG is set, > it is added to "all" > > (3) Make's "bundle" will copy (update if not there) all used Qt frameworks to > app's bundle Frameworks and used plugins to Plugins (currently implemented as > separate macdeployqt) > > NOTES: > > * Since qmake knows which Qt libraries and plugins are used "bundle" target > it will generate following Makefile entries > > all: Sample.app bundle > > bundle: Sample.app/Frameworks/QtCore.framework > mkdir -p Sample.app/Frameworks && cp -r > $$[QT_INSTALL_LIBS]/QtCore.framework Sample.app/Frameworks > ... > > Of course this example is simplification, since we don't need to copy headers > and we need to take debug versions or release. So there will be more commands > in practice. > > * One can disable "bundle_frameworks" via CONFIG -= bundle_frameworks, so > existing workflow where executable is given rpath pointing to Qt libraries > > * If disabled, one can still do "make bundle" that is equivalent to current > "macdeployqt" and "bundle" target will also add "install_name_tool" -rpath > replacement steps > one can still do "make bundle" that is equivalent to current "macdeployqt" Actually there is one huge difference between the two, and I’m not sure how this would work with the make target: a) macdeployqt works on all libraries that are in the bundle the moment it is executed, and b) it is possible to tell macdeployqt to make other executables/applications also use the same bundled Qt. (a) e.g. the Qt Creator build creates the application, and a whole bunch of plugin dylibs with DESTDIR in the bundle. The rpaths should just be correct from the start, probably no problem there, but some libraries there add dependencies to the Qt libraries that are needed. The main application is pretty minimal. So, depending on dylib target sub-.pro files, the list of Qt libraries to bundle with the *application* needs to change. (b) e.g. we have quite a few tools shipped in the Qt Creator bundle, which are either used by Qt Creator internally (e.g. for iOS device detection, starting the simulator,...), or shipped for convenience (the qbs that Qt Creator is linked against, etc). We definitely do not want to have separate Qt frameworks for these, but want them to use the frameworks from the Qt Creator application. With macdeployqt we tell it about the additional executables, and macdeployqt takes care of bundling additional required Qt frameworks, and fixing install names/rpaths correspondingly. -- 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
