[CMake] Gathering up required shared libraries

[Clinton Stimpson]

On Tuesday, August 02, 2011 06:36:45 pm David Cole wrote:
> On Tue, Aug 2, 2011 at 8:05 PM, Clinton Stimpson <clinton at elemtech.com> 
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