You realize you don't have to edit a CMakeLists.txt file to use a different value for a find_library result, right?<br><br>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:<br>
<br> cmake -DBOOST_ROOT=/path/to/boost ../src<br><br><br>HTH,<br>David<br><br><br><div class="gmail_quote">On Tue, Oct 4, 2011 at 7:20 AM, Daniel Dekkers <span dir="ltr"><<a href="mailto:d.dekkers@cthrough.nl">d.dekkers@cthrough.nl</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi,<br>
<br>
Would really appreciate your advice on this.<br>
<br>
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, ...<br>
This library would be able to target Windows (Glut), Mac OS X (Glut) and iOS (OpenGL ES1 and ES2).<br>
<br>
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.<br>
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:<br>
<br>
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.<br>
<br>
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.<br>
<br>
Something like:<br>
<br>
project(all)<br>
set(BOOST_ROOT path/to/boost)<br>
find_package(Boost ...)<br>
set(GLUT_ROOT_PATH path/to/glut)<br>
find_package(GLUT ...)<br>
...<br>
add_subdirectory(MyApp)<br>
add_subdirectoy(OurLib)<br>
<br>
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).<br>
<br>
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.<br>
<br>
4) Something different ;-)<br>
<br>
Thanks,<br>
Daniel Dekkers<br>
<font color="#888888"><br>
--<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</font></blockquote></div><br>