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.med...@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.c...@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.med...@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 > > > > >
_______________________________________________ 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