>
> 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
