On Tue, Jan 11, 2011 at 4:21 PM, Crni Gorac <span dir="ltr"><<a href="mailto:cgorac@gmail.com">cgorac@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><div></div><div class="h5">On Tue, Jan 11, 2011 at 6:22 PM, David Cole <<a href="mailto:david.cole@kitware.com">david.cole@kitware.com</a>> wrote:<br>
> On Tue, Jan 11, 2011 at 12:08 PM, Michael Jackson<br>
> <<a href="mailto:mike.jackson@bluequartz.net">mike.jackson@bluequartz.net</a>> wrote:<br>
>><br>
>> This is wonderful and I am making progress but I have a few more<br>
>> questions. Assume I am using CMake 2.8.3 (as it will become the<br>
>> requirement).<br>
>><br>
>> For external Dylibs and frameworks that my project depends on will the<br>
>> new way that bundle utilities work still copy the frameworks (like Qt<br>
>> frameworks) and external libraries (like HDF5, libTiff .. ) that are NOT<br>
>> part of my project? So my project builds its own couple of libraries (AIMLib<br>
>> & MXADataModel) but also depends on some external libraries (HDF5, libTiff,<br>
>> Expat, Boost). Do I need to have install rules or otherwise get those copied<br>
>> into the the bundle BEFORE calling fixup_bundle()?<br>
><br>
> No -- if we did that, BundleUtilities would truly be nearly useless. :-)<br>
><br>
> If a prerequisite is pulled in via dependency analysis, then fixup_bundle<br>
> will still copy it in (assuming it's not classified as a "system" library<br>
> ("system" == assumed to be pre-installed and available everywhere...))<br>
><br>
> The change was made only for the "additional libraries" passed in as the<br>
> parameter to fixup_bundle, which primarily equates to plugins...<br>
><br>
> The idea is: you know the additional libraries anyway because you're passing<br>
> them in, so you should install them in the bundle beforehand and pass in the<br>
> names just for prerequisite analysis and fixup. The additional libraries<br>
> will not show up in the prerequisites analysis because they are typically<br>
> only loaded dynamically at runtime. Hard links to non-system frameworks and<br>
> libraries will be copied in and fixed up.<br>
<br>
</div></div>I hope you guys don't mind if I jump in and re-ask related question I<br>
posted couple days ago (I'm sure Michael will soon face the same<br>
problem, if he's building also for for Mac, so he may be interested<br>
too): Is it possible with all this BundleUtilities mechanism to have<br>
these prerequisite library/plugin files, that fixup_bundle() is<br>
copying in, stripped? On Qt SDK for Mac, Qt libraries and plugins are<br>
not stripped, and thus generated package/installer gets rather<br>
large...<br>
<br>
Thanks.<br>
<div><div></div><div class="h5">_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a></div></div></blockquote></div><div><br></div><br><div>"Stripping" during fixup_bundle would be a good feature request for a future CMake release. We could do it simply by adding a variable that controls whether stripping gets done or not, and then setting that variable to OFF by default so that it behaves the same as it does now unless you explicitly enable it.</div>
<div><br></div><div>Does anybody have time to work up a patch to do this?</div><div><br></div><div><br></div><div>David</div><div><br></div>