Re: [CMake] copy_resolved_item_into_bundle doesn't copy when I want it to
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
Re: [CMake] copy_resolved_item_into_bundle doesn't copy when I want it to
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
Re: [CMake] copy_resolved_item_into_bundle doesn't copy when I want it to
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
[CMake] copy_resolved_item_into_bundle doesn't copy when I want it to
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
