On Tuesday, August 02, 2011 06:36:45 pm David Cole wrote: > On Tue, Aug 2, 2011 at 8:05 PM, Clinton Stimpson <[email protected]> wrote: > > 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 > > Let's not lose sight of the intent behind fixup_bundle here. I don't > want to confuse things by trying to make it all things to all people. > > For our purposes, a "bundle" is a relocatable file system entity (a > directory) which contains a set of executables and libraries that > after fixup, are entirely self-contained, referring to each other only > by relative paths, and will work on any compatible OS, regardless of > where they are placed in the target file system. > > On the Mac, this is achieved by copying external libraries "into the > bundle" and fixing up their references. Elsewhere, this is typically > achieved by copying libraries into the same directory with the > executable (on Windows, just works, on Linux, works as long as you use > $ORIGIN RPATH references). > > When you do not have a ".app" directory, and you are not copying into > the same directory with the executable, then the question in my mind > becomes "what exactly is 'the bundle' at this point?" > > With a dir/bin, dir/lib typical Linux style layout, "dir" would be > "the bundle"... > > If we really want to support this, perhaps we need another function to > extend fixup_bundle so that you pass in the bundle's directory, and > its main executable, or a list of executables. Instead of trying to > derive it from just the main executable like we do now. >
Ok.. that does sound like a good idea. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com _______________________________________________ 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
