[CMake] Incorporating third party libraries

David Cole david.cole at kitware.com
Tue Oct 4 11:07:33 EDT 2011


You realize you don't have to edit a CMakeLists.txt file to use a different
value for a find_library result, right?

You can just set the value of the variables in cmake-gui as an "end user
developer (client of OurLib)" -- or, if you know the set of needed variable
values in advance, you can do it from the cmake command line with -D:

  cmake -DBOOST_ROOT=/path/to/boost ../src


HTH,
David


On Tue, Oct 4, 2011 at 7:20 AM, Daniel Dekkers <d.dekkers at cthrough.nl>wrote:

> 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
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20111004/857c347f/attachment.html>


More information about the CMake mailing list