[CMake] [CMAKE] Handling External Libraries and Resources

[Ben Medina]

We've struggled with the same issue, and for out latest project, we've
switched to using fixup_bundle to handle the installation of 3rd party
lib dependencies, rather than copying them into the build tree as a
build step.

To ensure that developers can still easily launch the app for
debugging, on Windows we create a custom vcproj.user file that
specifies a custom PATH environment variable. On Linux, we create a
custom shell script that specifies additional entries to
LD_LIBRARY_PATH before it launches the app. We're not currently using
XCode, so I'm not sure what's involved there.

- Ben

On Wed, May 12, 2010 at 6:09 PM, Patrik Gornicz <gornicz_p at hotmail.com> wrote:
>
>
> Sorry about the subject line.
>
> I've never posted to a mailing list before and I wasn't sure if [CMake] would be automatically prepended or not, plus it seems I didn't do it correctly myself ...
>
> Patrik Gornicz
>
>> From: gornicz_p at hotmail.com
>> To: cmake at cmake.org
>> Date: Wed, 12 May 2010 18:12:20 -0400
>> Subject: [CMake] [CMAKE] Handling External Libraries and Resources
>>
>>
>>
>> I've been tasked with developing a new build system for projects at my work
>> place. We decided to use CMake and have been quite pleased thus far. However,
>> we've run into a requirement we haven't been able to satisfy to our satisfaction.
>>
>> The requirement is with respect to handling external libraries and resources
>> when building.  By external libraries I mean libraries that the CMake system
>> itself does not build (ex. boost, third party libraries, etc.) but we want to
>> use without having to install them on the system (ie. keep them local to our
>> build tree).  By resources I mean anything else that our binaries require to
>> function normally (ex. images, music, audio clips, localized text files, etc.)
>>
>> Essentially, we want a directory, say targetdir, were all our runtime required
>> files get built or copied into such that the program can execute in a developer
>> friendly way using both XCode and Visual Studio.
>>
>> What is the best way to do this with CMake?
>>
>>
>> Requirements:
>>   * Must work well with XCode on the Mac, GNU Make on the Mac, and Visual
>>     Studio on Windows.
>>   * Updating resources and/or external libraries should cause their versions in
>>     the targetdir to get updated (ie. Dependency tracking)
>>
>> Reasons for desiring a targetdir:
>>   * Our application loads resources (ex. images) using paths relative to the
>>     main executable. (rather common, no?)
>>   * On Windows there is no rpath option to tell Windows where to search for
>>     dlls (at least to the best of my knowledge there isn't), hence, dlls need
>>     to be side-by-side with our main executable.
>>   * Its nice to have everything required to run a program in one location so an
>>     installer can be created without having everything scattered around a build
>>     tree.
>>
>> What we are currently doing:
>>   * Build all of our shared libraries and binaries into this target directory.
>>     * Ex. set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/targetdir")
>>     * Ex. set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/targetdir")
>>   * Manually keeping track of and copying external libraries and resources into
>>     this target directory.
>>     * CON: There doesn't seem to be a way to create custom commands and have a
>>            non custom target use/execute them.
>>       * Hence, we've created an addition target (called App-build-resources)
>>         which is a custom target and runs our custom copying code and the App
>>         target depends on this addition target.
>>     * CON: Currently we only have resources associated with applications
>>            (binaries), but it would be nice to have resources associated with
>>            libraries.
>>       * ie. It would be nice if a library copied resources it needs into the
>>             location it is being built. Currently this would require a
>>             Lib-build-resources target per library which is quite ugly.
>>     * PRO: A developer can select the App target (ex. Set As StartUp Project in
>>            Visual Studio) and simply build knowing that the custom target will
>>            run before the App target is considered up to data.
>>     * PRO: A developer can simply execute the App target after building
>>            directly because the App target creates the main executable.
>>     * CON: The CMake code is rather ugly due to the large amount of manual work going on.
>>       * Keeping track of what external file to link against and making targets
>>         link against it.
>>       * Keeping track of what external file and resources need to be copied
>>         into the targetdir.
>>
>> Other things we've tried or considered:
>>   * Using an INSTALL target that copies all of the built binaries, libraries,
>>     external libraries and resources into a directory that is within the source
>>     tree.
>>     * CON: Both XCode and Visual Studio cannot easily execute the installed versions.
>>       * ex. The binary copied by INSTALL is not the target of the Visual Studio
>>             project, hence, trying to run it from within Visual Studio results
>>             in a "The system cannot find the path specified error".
>>   * Using the IMPORTED property for external libraries.
>>     * CON: Does not solve the issue with respect to resources.
>>       * Why shouldn't the ideal solution be able to handle resources just as easily?
>>     * CON: We seemed to run into a scoping issue where an IMPORTED library
>>            could only be referenced in the directory (and subdirectories) where
>>            a non IMPORTED library is global. (is this a bug?)
>>       * Due to the layout of our source tree this was problematic. (we worked
>>         around it by using includes instead of add_subdirectorys, though we
>>         didn't like that very much)
>>   * Instead of doing the copying at build time (ie. by XCode/Visual Studio) do
>>     the copying at build generation time (ie. by CMake)
>>     * CON: XCode and Visual Studio have per-configuration output directories,
>>            hence, CMake has to copy the files into each of these directories.
>>     * CON: Dependencies aren't really tracked.
>>       * If one developer updates an image another developer has to remember to
>>         manually run CMake when they sync to trigger the copy. (The ZERO_CHECK
>>         CMake run doesn't get triggered by such an update)
>>   * Custom target that always runs and executes a GNU Makefile to handle
>>     copying of resources and external libraries.
>>     * CON: Shouldn't really be necessary, and would require extra work.
>>
>>
>> Essentially, I'd like to hear your views on handling resource copying. Is
>> there an obvious method I've overlooked? What are other projects doing to
>> handle resources? Any ideas with respect to other methods of handling resources?
>>
>> Thanks for your time,
>> Patrik Gornicz
>>
>> _________________________________________________________________
>> 30 days of prizes: Hotmail makes your day easier! Enter Now.
>> http://go.microsoft.com/?linkid=9729710
>> _______________________________________________
>> 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
>
> _________________________________________________________________
> 30 days of prizes: Hotmail makes your day easier! Enter Now.
> http://go.microsoft.com/?linkid=9729710
> _______________________________________________
> 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
>