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 <[email protected]> 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 <[email protected]> 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
