[CMake] Incorporating third party libraries
Daniel Dekkers
d.dekkers at cthrough.nl
Tue Oct 4 07:20:13 EDT 2011
Hi,
Would really appreciate your advice on this.
We are planning to use and maybe distribute a library (let's call it OurLib) that depends on third-party libraries, namely Boost, Glut, OpenGL, FreeType, Bullet, PNG, ...
This library would be able to target Windows (Glut), Mac OS X (Glut) and iOS (OpenGL ES1 and ES2).
At the moment, (parts of) these third-party libraries are just added as sources to OurLib, which releases us of the burden of performing proper individual builds of the third-party libraries for the different platforms/architectures. Namely iOS is not very widely adopted yet, with the arm architecture and all.
This in-source approach works nicely but isn't the way to go, I guess. Apart from the problem of providing builds for the third-party libraries outside OurLib, we also have to incorporate them. The question how to do that:
1) In the CMakeLists.txt of the OurLib library itself use find_package()/find_library() to find the third-party libraries? This would imply that the user of the library would have to change these "[LIBNAME]_ROOT "or "[LIBNAME]_ROOT_PATH" kinds of variables in the CMakeLists.txt of the OurLib library itself to find the third-party libraries on their particular platform.
2) Insist on a "top level" user-dependent CMakeLists.txt that would perform find_package()/find_library() before diving into the application sources and library sources.
Something like:
project(all)
set(BOOST_ROOT path/to/boost)
find_package(Boost ...)
set(GLUT_ROOT_PATH path/to/glut)
find_package(GLUT ...)
...
add_subdirectory(MyApp)
add_subdirectoy(OurLib)
That way, at least, people don't have to edit the distributed CMakeLists.txt of OurLib itself. And you have a central place to do find_package()/find_library() so users can use the libraries in their own applications as well (which is often the case).
3) Just leave it to the user to do the find_package()/find_library() in their own CMakeLists.txt of their individual app before diving into the source directory of OurLib, which would be called from the CMakeLists.txt of their own application.
4) Something different ;-)
Thanks,
Daniel Dekkers
More information about the CMake
mailing list