On Aug 2, 2011, at 5:47 PM, Gregory Crosswhite wrote: > On 8/2/11 4:32 PM, Clinton Stimpson wrote: >> There is no scanning the file system to find which libraries to fix up. >> Any libraries used by executables will be considered in the set of libraries >> to fix up, regardless of where they are installed (in bin/ or lib/). Any >> libraries not found as a dependency can be specified by the second parameter >> of >> fixup_bundle(). Plugins are a typical example of that, because executables >> and >> libraries don't link against plugins. > > Doh! For some reason I thought I saw that the code was doing that but I see > now that I was mistaken. > >> You don't need to add your libraries to the second parameter. If you did, >> you'd have to know them all up front, and that defeats one of the purpose of >> BundleUtilities. > > Sorry, I obviously didn't make it clear that I was referring to libraries > that I was not planning on linking the program against --- that is, libraries > provided for the benefit of other developers but not actually used by my > program. Having said that, discussing this has made me realize that in my > case it would probably make more sense for me to link against my own shared > library anyway to prevent code from being duplicated in both program and > library, so my use case is not as likely as I had been originally imagining.
Oh, so you're also providing libraries for other developers. In that case, you do specify them into the second parameter of fixup_bundle(). If those libraries have additional dependencies, then BundleUtilities could be useful for that. Clint _______________________________________________ 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
