[QBS] Post Build process to install_name_tool

[Jake Petroules]

On 2014-09-04, at 12:28 PM, Christian Kandeler <christian.kandeler at digia.com> 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
> QBS at qt-project.org
> 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.
-- 
Jake Petroules - jake.petroules at petroules.com
Chief Technology Officer - Petroules Corporation