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 <[email protected]>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 >
-- 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
