> > Hi Chuck (off list): > Hi Alan (on list)
> but the one above I completely missed. ... > with the hint above I should be able to figure out > all those remaining issues on my own Excellent! Glad to hear it. Inconsistent path quoting is a common pitfal when writing portable CMake code. It bites all of us at one point or another, even Brad sometimes. Glad I could help. > Or even better, don't blow away the current module path, jsut append to >>> the front: >>> list(INSERT CMAKE_MODULE_PATH 0 "${CMAKE_SOURCE_DIR}/cmake/Modules") >>> >> > What is the use case you had in mind for not blowing away > CMAKE_MODULE_PATH? Does CMake itself sometimes set CMAKE_MODULE_PATH > so blowing away this variable by setting it in the top-level > CMakeLists.txt file (something that is done in all the CMake-based > build systems I have helped to implement) could cause problems? The typical use case is when your package is being used as a third party library by somebody else. There are many different ways that could be done but for small dependencies, a typical approach is to just place the code in a subdirectory and add it to an existing build with add_subdirectory. In this case, the calling project has set up the environment in a particular way and your forcibly throwing it away. There's other use cases for it but it's typically good practice to make yourself work within an existing environment rather than ignore the environment and create your own unless you have a specific reason (other than I don't know what they're going to do) I wouldn't want to allow such freedom to users of software packages I am > associated with since it implies a significant increase (more things > that could possibly go wrong) in the support burden for each such > project. It's certainly up to you since it's your code but if you're distributing source then somebody will just change it anyway if that's their use case. Using the insert instead of set allows both uses cases; i.e. as a standalone library or a third party library included by a larger CMake project, so why limit it. - Chuck
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers