Le 04/09/2014 18:40, Jake Petroules a écrit : > On 2014-09-04, at 12:28 PM, Christian Kandeler <[email protected]> > wrote: > >> Hi, >> >> On 09/04/2014 05:33 PM, olivier musse wrote: >>> With QBS 1.3 we are trying to defined a post build process on our >>> product (a dynamiclibrary) to call install_name_tool in order to change >>> some library dependencies. >>> For that we defined the following rule (MyLib is defined as a type of >>> the product) >>> Rule{ >>> >>> inputs: ['dynamiclibrary'] >>> >>> Artifact { >>> >>> filePath: input.filePath >>> >>> fileTags: "MyLib"} >>> >>> prepare: { >>> >>> ...... >>> >>> } >>> >>> } >>> >>> >>> When doing that, we get a conflict rule message with the internal qbs >>> file (GenericGCC.qbs:113:18) >>> Apparently this is because our rule as the same file as input and output. >> in general, the question of how to "enrich" a build artifact is an >> unsolved problem. I think https://bugreports.qt-project.org/browse/QBS-5 >> is referring to this issue as well. >> But for your case, why not just use cpp.installNamePrefix? >> >>> With previous version of QBS it was possible to do it. >> I don't think so. Can you give an example project where you do that >> which works with qbs 1.2 but not wit 1.3? >> >> >> Christian >> _______________________________________________ >> QBS mailing list >> [email protected] >> http://lists.qt-project.org/mailman/listinfo/qbs > > Any solution that uses install_name_tool is, 99% of the time, a broken > solution (the only valid case I can think of is where a binary-only third > party library you're using has a wrong install name). Certainly for your own > code, you should be using the linker flags -install_name and -rpath, which > are accessible in qbs using the cpp.installNamePrefix and cpp.rpaths > properties. > > Almost all of the time, cpp.installNamePrefix should be set to "@rpath", and > cpp.rpaths should generally be @executable_path/../Frameworks or > @loader_path/../Frameworks depending on where a given binary's dependencies > reside (note that rpaths is a LIST, so you can have multiple search paths). > > Also see Apple's documentation on dyld: > https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html > (relevant parts at the bottom). > > Hope that helps. Hi,
Thanks for these informations, they are precious. In fact we are already using the cpp.rpaths property and the cpp.installNamePrefix property is not documented. Whatever this does not work for our case but perhaps we are not using it the right case. Our case is the following : we develop plugins for a not Qt application and we need to deploy Qt with the plugins (Qt is not installed on the target platform and must be automatically deployed with the application) So with the cpp.installNamePrefix, only the install_name of the executable is set to "@rpath" and we would like it also to be set for Qt library So we have something like @rpath/AudioPlugin (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 57.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.0.0) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) /usr/local/qt-5.3.0-mana/lib/QtCore.framework/Versions/5/QtCore (compatibility version 5.3.0, current version 5.3.0) /usr/local/qt-5.3.0-mana/lib/QtGui.framework/Versions/5/QtGui (compatibility version 5.3.0, current version 5.3.0) /usr/local/qt-5.3.0-mana/lib/QtNetwork.framework/Versions/5/QtNetwork (compatibility version 5.3.0, current version 5.3.0) /usr/local/qt-5.3.0-mana/lib/QtMultimedia.framework/Versions/5/QtMultimedia (compatibility version 5.3.0, current version 5.3.0) /usr/local/qt-5.3.0-mana/lib/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.3.0, current version 5.3.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) and we need to have something like @rpath/AudioPlugin (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 57.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.0.0) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.3.0, current version 5.3.0) @rpath/QtGui.framework/Versions/5/QtGui (compatibility version 5.3.0, current version 5.3.0) @rpath/QtNetwork.framework/Versions/5/QtNetwork (compatibility version 5.3.0, current version 5.3.0) @rpath/QtMultimedia.framework/Versions/5/QtMultimedia (compatibility version 5.3.0, current version 5.3.0) /usr/local/qt-5.3.0-mana/lib/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.3.0, current version 5.3.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) Since we are not experimented OSX developers (sorry for that) we are perhaps not doing well. Many thanks in advance for you help Regards Olivier _______________________________________________ QBS mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qbs
