[CMake] [CMAKE] Handling External Libraries and Resources

[Patrik Gornicz]

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