[CMake] Gathering up required shared libraries

[Clinton Stimpson]

On Tuesday, August 02, 2011 05:09:04 pm Gregory Crosswhite wrote:
> On 08/02/2011 03:10 PM, Clinton Stimpson wrote:
> > On Tuesday, August 02, 2011 03:38:01 pm Gregory Crosswhite wrote:
> > You need an @ONLY for configure_file() so it doesn't substitute the ${}
> > parts also.
> 
> Doh!  Thanks for the tip.  :-)
> 
> > You should either pass in the executable or a .app/ directory to
> > fixup_bundle()
> 
> Okay, but what if I have my own shared libraries that I also want to
> fixup that get installed in lib/? 

They will get fixed up if they are either referenced by an executable in the 
bin directory, or if its passed in the second argument of fixup_bundle().

> It would be preferable if
> fixup_bundle were to scan not only everything in bin/ but also
> everything in lib/, since it searches recursively for both executables
> and libraries in the bundle directory, and that is set to bin/ ---
> though I suppose I could work around this manually by passing in all of
> the libraries that get installed into lib/ into the second argument of
> fixup_bundle().

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.

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.

> 
> > But after those fixes... there is another error that says:
> > "Install or copy the item into the bundle before calling fixup_bundle.
> > Or maybe there's a typo or incorrect path in one of the args to
> > fixup_bundle?"
> > 
> > I thought that check applied only to parameters passed in the second
> > argument of fixup_bundle(), so that looks like a bug.  That function is
> > also only called on Mac if that helps explain some behavior you are
> > seeing.
> > If I comment out the FATAL_ERROR it issues, then it completes and gives a
> > working installation.  Would you like to file a bug report for this?
> 
> I went ahead and file a bug report describing my issue:
> http://public.kitware.com/Bug/view.php?id=12382
> 
> However, in response to your remark that "I thought that check applied
> only to parameters passed in the second argument", consider that even if
> this were true then there would still be a problem.  To see why,
> consider the following example (again, all sources attached to this
> e-mail):
> 
> ===== CMakeLists.txt =====
> cmake_minimum_required(VERSION 2.8.5)
> 
> set(CMAKE_INSTALL_PREFIX ${CMAKE_BINARY_DIR}/bundle)
> 
> add_executable(hello hello)
> add_library(hellolib SHARED hellolib)
> install (TARGETS hello DESTINATION bin)
> install (TARGETS hellolib DESTINATION lib)
> 
> configure_file(
>      ${CMAKE_SOURCE_DIR}/FixBundle.cmake.in
>      ${CMAKE_BINARY_DIR}/FixBundle.cmake
>      @ONLY
> )
> install(SCRIPT ${CMAKE_BINARY_DIR}/FixBundle.cmake)
> 
> ===== FixBundle.cmake.in =====
> include (BundleUtilities)
> 
> fixup_bundle(
>    "${CMAKE_INSTALL_PREFIX}/bin/hello at CMAKE_EXECUTABLE_SUFFIX@"
> 
> "${CMAKE_INSTALL_PREFIX}/lib/@CMAKE_SHARED_LIBRARY_PREFIX at hellolib@CMAKE_SH
> ARED_LIBRARY_SUFFIX@" "@LIBRARY_OUTPUT_PATH@"
> )
> 
> =====================
> 
> The resulting error message is
> 
> =====================
> -- Install configuration: ""
> -- Up-to-date:
> /Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle/bin/
> hello -- Installing:
> /Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle/lib/
> libhellolib.dylib -- fixup_bundle
> --
> app='/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle
> /bin/hello' --
> libs='/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundl
> e/lib/libhellolib.dylib' --   dirs=''
> -- fixup_bundle: preparing...
> -- fixup_bundle: copying...
> -- 1/4: *NOT* copying
> '/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle/lib
> /libhellolib.dylib' -- 2/4: *NOT* copying
> '/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle/bin
> /hello' -- fixup_bundle: fixing...
> -- 3/4: fixing up
> '/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle/lib
> /libhellolib.dylib'
> 
> exe_dotapp_dir/='/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/
> build/bundle/bin/'
> 
> item_substring='/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/b
> uild/bundle/lib/'
> 
> resolved_embedded_item='/Users/gcross/Documents/ThrowawayCode/cmake-issue-e
> xample/build/bundle/lib/libhellolib.dylib'
> 
> Install or copy the item into the bundle before calling fixup_bundle.
> Or maybe there's a typo or incorrect path in one of the args to
> fixup_bundle?
> 
> CMake Error at /Applications/CMake
> 2.8-5.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:568
> (message):
>    cannot fixup an item that is not in the bundle...
> Call Stack (most recent call first):
>    /Applications/CMake
> 2.8-5.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:656
> (fixup_bundle_item)
>    FixBundle.cmake:3 (fixup_bundle)
>    cmake_install.cmake:54 (INCLUDE)
> =====================
> 
> Given this as well as my previous remark in this e-mail, it looks to me
> like that the best and easiest way to both solve all these problems and
> also allow libraries to be automatically recursively found within the
> bundle like executables is just to allow the user to override the bundle
> directory.

If you copy BundleUtilities/GetPrerequisites and remove the FATAL_ERROR 
issued.  Then the installation is fixed up correctly, including the libraries 
in lib/.  The fix for this bug is to modify that error check.

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com