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

[David Cole]

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).

Otherwise, simply before whatever it is that initially creates the bundle on
which you are calling fixup_bundle...


On Tue, Dec 21, 2010 at 12:12 PM, Ben Medina <ben.medina at gmail.com> wrote:

> 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20101221/bc9316cf/attachment.htm>