<div class="gmail_quote">I would think immediately before the first install rule that installs the bundle itself or something into the bundle location (assuming you have such a thing).<br><br>Otherwise, simply before whatever it is that initially creates the bundle on which you are calling fixup_bundle...<br>
<br><br>On Tue, Dec 21, 2010 at 12:12 PM, Ben Medina <span dir="ltr"><<a href="mailto:ben.medina@gmail.com">ben.medina@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
That sounds fine. However, I have install rules located in multiple<br>
files; my project contains multiple apps, and each apps has its<br>
install rules in its own lists file. Where do I put my "delete bundle"<br>
install code to ensure that it runs before all other install commands?<br>
<br>
Thanks,<br>
<font color="#888888">Ben<br>
</font><div><div></div><div class="h5"><br>
On Tue, Dec 21, 2010 at 4:04 AM, David Cole <<a href="mailto:david.cole@kitware.com">david.cole@kitware.com</a>> wrote:<br>
> copy_resolved_item_into_bundle only skips the copy if the file to be copied<br>
> and the destination file refer to exactly the same file. In that sense, it<br>
> already is a copy_if_different.<br>
><br>
> On the Mac, after a bundle is created and fixed up for the first time, all<br>
> the references from one library to another are "internal to the bundle" via<br>
> @executable_path references. Once that is done, the entities which had<br>
> originally referred to external libraries (typically by their full path<br>
> names in the build tree) no longer refer to those external libraries, but to<br>
> the copies inside the bundle.<br>
><br>
> Now, the second time fixup_bundle runs, there is nothing that refers to that<br>
> library in the build tree *unless* one of your install rules places<br>
> something new inside the bundle that has an external reference again. If you<br>
> have simply rebuilt a library that got pulled in via the first call to<br>
> fixup_bundle, there is nothing that will pull in the new copy again. (That's<br>
> sort of the point of fixup_bundle is to break those "external" references.)<br>
><br>
> So... this is basically a long-winded, explanatory way of saying "don't do<br>
> that." :-)<br>
><br>
> For your workflow to be bullet-proof, you should delete the bundle at step<br>
> 2.5 -- after changing one of the pulled in libraries, but before running<br>
> "make install" again. Perhaps it would even be best to put in a "delete<br>
> bundle" step as the very first part of "make install", just as a call to<br>
> "fixup_bundle" is typically your very last step of make install.<br>
><br>
> I realize this is non-ideal, but I think it's reasonable given the benefit<br>
> that fixup_bundle provides. As always, I'm open to discussion and<br>
> suggestions if anybody has ideas for improving BundleUtilities.<br>
><br>
><br>
> HTH,<br>
> David<br>
><br>
><br>
> On Mon, Dec 20, 2010 at 6:44 PM, Ben Medina <<a href="mailto:ben.medina@gmail.com">ben.medina@gmail.com</a>> wrote:<br>
>><br>
>> Hello all,<br>
>><br>
>> I'm using fixup_bundle as part of my installation rules. One problem<br>
>> I've run into is that if you build the install target multiple times,<br>
>> fixup_bundle (or, more specifically, copy_resolved_item_into_bundle)<br>
>> won't copy a library over if it's coming from the same location. This<br>
>> causes a failure for the following workflow:<br>
>><br>
>> 1. Build the install target.<br>
>> 2. Make a change to one of the libraries that fixup_bundle resolved for<br>
>> you.<br>
>> 3. Build the install target again.<br>
>><br>
>> The second time you build the install, the updated library does not<br>
>> get copied, and any application that depends on the change in that<br>
>> library will be broken.<br>
>><br>
>> Is there is reason copy_resolved_item_into_bundle doesn't just use<br>
>> copy_if_different?<br>
>><br>
>> Thanks,<br>
>> Ben<br>
>> _______________________________________________<br>
>> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
>><br>
>> Visit other Kitware open-source projects at<br>
>> <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:<br>
>> <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><br>
><br>
><br>
</div></div></blockquote></div><br>