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

Reply via email to