On Wed, Dec 16, 2009 at 1:48 AM, Michael Wild <span dir="ltr"><<a href="mailto:themiwi@gmail.com">themiwi@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On 15. Dec, 2009, at 23:46 , Glenn Hughes wrote:<br>
<br>
>> I think the SDL developers are just being a bit "too" slick. They are setting up SDL for Xcode development where typically you would link to the SDL and then have a "Copy Files Phase" where you copy the framework into the Application Bundle that resides in the build directory.<br>
><br>
> Its a cultural difference also. Mac developers think of creating the<br>
> complete application as part of the build process. A Mac app generally<br>
> contains everything it needs so you can just drag it to another<br>
> machine and run it. I would never want a half-baked app that is wired<br>
> into my machine. Copying the libraries into the app isn't part of<br>
> "installation", its part of "building"... Copying the app somewhere<br>
> else is "installation" i.e. a no-op as far as my build process is<br>
> concerned.<br>
><br>
> G<br>
<br>
</div>In the case of OS X bundles, don't think of it like "installation". It's more like "finishing up".<br>
<br>
How about adding some logic to target_link_libraries that writes a file, similar to depend.internal, mapping the install-name of the linked libraries to their location (if a full path has been used for linking). This file could then be used by BundleUtilities.cmake. Probably one would need to black-list certain directories (such as /System/Library/Frameworks), or is this already done?<br>
<font color="#888888"><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#888888"><br></font></font></font></blockquote><div><br></div><div>BundleUtilities avoids copying "system" files -- they are expected to be installed everywhere by virtue of the fact that they "belong" to the OS. Files in /System do not get copied in by default with the BundleUtilitles fixup routines.</div>
<div><br></div><div>Most of our examples of using BundleUtilities occur at "make install" time via cmake scripts, but you could just as easily use them as part of a post-build custom command step on your bundle, as long as all of the dependent pieces are ready to be assembled.</div>
<div><br></div><div>HTH,</div><div>David</div><div><br></div></div>