[CMake] Gathering up required shared libraries

[David Cole]

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.


David C.