[CMake] copy_resolved_item_into_bundle doesn't copy when I want it to

[Ben Medina]

That sounds fine. However, I have install rules located in multiple
files; my project contains multiple apps, and each apps has its
install rules in its own lists file. Where do I put my "delete bundle"
install code to ensure that it runs before all other install commands?

Thanks,
Ben

On Tue, Dec 21, 2010 at 4:04 AM, David Cole <david.cole at kitware.com> wrote:
> copy_resolved_item_into_bundle only skips the copy if the file to be copied
> and the destination file refer to exactly the same file. In that sense, it
> already is a copy_if_different.
>
> On the Mac, after a bundle is created and fixed up for the first time, all
> the references from one library to another are "internal to the bundle" via
> @executable_path references. Once that is done, the entities which had
> originally referred to external libraries (typically by their full path
> names in the build tree) no longer refer to those external libraries, but to
> the copies inside the bundle.
>
> Now, the second time fixup_bundle runs, there is nothing that refers to that
> library in the build tree *unless* one of your install rules places
> something new inside the bundle that has an external reference again. If you
> have simply rebuilt a library that got pulled in via the first call to
> fixup_bundle, there is nothing that will pull in the new copy again. (That's
> sort of the point of fixup_bundle is to break those "external" references.)
>
> So... this is basically a long-winded, explanatory way of saying "don't do
> that." :-)
>
> For your workflow to be bullet-proof, you should delete the bundle at step
> 2.5 -- after changing one of the pulled in libraries, but before running
> "make install" again. Perhaps it would even be best to put in a "delete
> bundle" step as the very first part of "make install", just as a call to
> "fixup_bundle" is typically your very last step of make install.
>
> I realize this is non-ideal, but I think it's reasonable given the benefit
> that fixup_bundle provides. As always, I'm open to discussion and
> suggestions if anybody has ideas for improving BundleUtilities.
>
>
> HTH,
> David
>
>
> On Mon, Dec 20, 2010 at 6:44 PM, Ben Medina <ben.medina at gmail.com> wrote:
>>
>> Hello all,
>>
>> I'm using fixup_bundle as part of my installation rules. One problem
>> I've run into is that if you build the install target multiple times,
>> fixup_bundle (or, more specifically, copy_resolved_item_into_bundle)
>> won't copy a library over if it's coming from the same location. This
>> causes a failure for the following workflow:
>>
>> 1. Build the install target.
>> 2. Make a change to one of the libraries that fixup_bundle resolved for
>> you.
>> 3. Build the install target again.
>>
>> The second time you build the install, the updated library does not
>> get copied, and any application that depends on the change in that
>> library will be broken.
>>
>> Is there is reason copy_resolved_item_into_bundle doesn't just use
>> copy_if_different?
>>
>> Thanks,
>> Ben
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
>
>