Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
I thought they probably were. My question was really if the behaviour that results from that was desirable. I can't see any reason why they should be cached as they aren't user configurable variables. Would it break anything badly if they were not stored in the cache ? It would result in more consistent behaviour IMHO. -- Glenn On 28 April 2014 19:33, Matthew Woehlke mw_tr...@users.sourceforge.netwrote: On 2014-04-23 14:18, Glenn Coombs wrote: Are the [Project name]_SOURCE_DIR variables being automatically stored in the cmake cache? Running 'grep _SOURCE_DIR CMakeCache.txt' would answer this question. (And yes, they are.) -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
I thought they probably were. My question was really if the behaviour that results from that was desirable. I can't see any reason why they should be cached as they aren't user configurable variables. Would it break anything badly if they were not stored in the cache ? It would result in more consistent behaviour IMHO. Executing cmake . would fail in the bin folder if it had no way to know where the source folder is. John -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
What I am saying is that project(foo) should internally execute the equivalent of set(foo_SOURCE_DIR /path/to/source) rather than set(foo /path/to/source CACHE STRING). That way it would fail on every run if you referenced a project source directory variable before you had done the add_subdirectory() for that project. Currently in that situation it fails the first time you run cmake but works as expected on subsequent runs of cmake, which I think is odd behaviour. On 1 May 2014 18:35, John Drescher dresche...@gmail.com wrote: I thought they probably were. My question was really if the behaviour that results from that was desirable. I can't see any reason why they should be cached as they aren't user configurable variables. Would it break anything badly if they were not stored in the cache ? It would result in more consistent behaviour IMHO. Executing cmake . would fail in the bin folder if it had no way to know where the source folder is. John -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
On Thu, May 1, 2014 at 1:54 PM, Glenn Coombs glenn.coo...@gmail.com wrote: What I am saying is that project(foo) should internally execute the equivalent of set(foo_SOURCE_DIR /path/to/source) rather than set(foo /path/to/source CACHE STRING). That way it would fail on every run if you referenced a project source directory variable before you had done the add_subdirectory() for that project. Currently in that situation it fails the first time you run cmake but works as expected on subsequent runs of cmake, which I think is odd behaviour. I am saying making this change to not cache the source folder would break cmake binfolder and cmake --build buildfolder and several other commands that have worked this way for years. John -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
On 2014-05-01 13:35, John Drescher wrote: I thought they probably were. My question was really if the behaviour that results from that was desirable. I can't see any reason why they should be cached as they aren't user configurable variables. Would it break anything badly if they were not stored in the cache ? It would result in more consistent behaviour IMHO. Executing cmake . would fail in the bin folder if it had no way to know where the source folder is. If CMAKE_BINARY_DIR were not cached, yes. But I don't think not caching that is being suggested. It's not clear to me why the *per-project* flavors need to be cached? -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
On Thu, May 1, 2014 at 2:16 PM, Matthew Woehlke mw_tr...@users.sourceforge.net wrote: On 2014-05-01 13:35, John Drescher wrote: I thought they probably were. My question was really if the behaviour that results from that was desirable. I can't see any reason why they should be cached as they aren't user configurable variables. Would it break anything badly if they were not stored in the cache ? It would result in more consistent behaviour IMHO. Executing cmake . would fail in the bin folder if it had no way to know where the source folder is. If CMAKE_BINARY_DIR were not cached, yes. But I don't think not caching that is being suggested. It's not clear to me why the *per-project* flavors need to be cached? I see now. Sorry for the noise.. John -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
On 01.05.2014 20:16, Matthew Woehlke wrote: If CMAKE_BINARY_DIR were not cached, yes. But I don't think not caching that is being suggested. It's not clear to me why the *per-project* flavors need to be cached? If they were regular instead of cache variables they would have scopes. I guess this would break any project that currently referred to their sub- or sibling projects with those variables. Nils -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
On Thu, May 1, 2014 at 11:26 AM, Nils Gladitz nilsglad...@gmail.com wrote: On 01.05.2014 20:16, Matthew Woehlke wrote: If CMAKE_BINARY_DIR were not cached, yes. But I don't think not caching that is being suggested. It's not clear to me why the *per-project* flavors need to be cached? If they were regular instead of cache variables they would have scopes. I guess this would break any project that currently referred to their sub- or sibling projects with those variables. Ya; promotion to global namespace via addition to cache is a good reason to have them cached But, it's not that you have a dynamic build structure that changes often? It's just that you're trying to reference a variable before it exists; and there's ways around that like set a CMAKE_PASS_2 variable or something to make sure that everything is done the next time... and it fails on a first-run .. but then it doesn't fail, so it's hard to track down where the error was? maybe cmake --trace ? -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
On 2014-05-01 14:26, Nils Gladitz wrote: On 01.05.2014 20:16, Matthew Woehlke wrote: If CMAKE_BINARY_DIR were not cached, yes. But I don't think not caching that is being suggested. It's not clear to me why the *per-project* flavors need to be cached? If they were regular instead of cache variables they would have scopes. I guess this would break any project that currently referred to their sub- or sibling projects with those variables. Hmm... that's a good point. I suspect project() could work around the scope at least by arranging to set them in the root scope, but there might be other, related issues that could arise. Nuts :-). -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
Okay, I think I understand what you're saying. Variables set in a CMakeLists.txt file added by add_subdirectory are only visible in that CMakeLists.txt and any further ones it adds via add_subdirectory. The higher level CMakeLists.txt files would not have the necessary visibility, hence the need to cache the project source directory variable. To make it behave consistently it would be necessary for cmake to be able to set a variable in the scope of the top level CMakeLists.txt. Similar to the PARENT_SCOPE that the set() command already has, something like set(foo_SOURCE_PROJECT path/to/source ROOT_SCOPE). I suspect that the reason cmake is caching these variable is because the set() command doesn't have a ROOT_SCOPE ability and using cache variables was the easiest way to simulate that. And we have to live with the unfortunate side effect that the cached variables don't exist on the first run but do on subsequent runs. On 1 May 2014 19:00, John Drescher dresche...@gmail.com wrote: On Thu, May 1, 2014 at 1:54 PM, Glenn Coombs glenn.coo...@gmail.com wrote: What I am saying is that project(foo) should internally execute the equivalent of set(foo_SOURCE_DIR /path/to/source) rather than set(foo /path/to/source CACHE STRING). That way it would fail on every run if you referenced a project source directory variable before you had done the add_subdirectory() for that project. Currently in that situation it fails the first time you run cmake but works as expected on subsequent runs of cmake, which I think is odd behaviour. I am saying making this change to not cache the source folder would break cmake binfolder and cmake --build buildfolder and several other commands that have worked this way for years. John -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
On 01.05.2014 20:38, Glenn Coombs wrote: Okay, I think I understand what you're saying. Variables set in a CMakeLists.txt file added by add_subdirectory are only visible in that CMakeLists.txt and any further ones it adds via add_subdirectory. The higher level CMakeLists.txt files would not have the necessary visibility, hence the need to cache the project source directory variable. To make it behave consistently it would be necessary for cmake to be able to set a variable in the scope of the top level CMakeLists.txt. Similar to the PARENT_SCOPE that the set() command already has, something like set(foo_SOURCE_PROJECT path/to/source ROOT_SCOPE). I suspect that the reason cmake is caching these variable is because the set() command doesn't have a ROOT_SCOPE ability and using cache variables was the easiest way to simulate that. And we have to live with the unfortunate side effect that the cached variables don't exist on the first run but do on subsequent runs. I don't think it would be sufficient to set it in the root scope either since I think each scope has its own copy of the variable. It would have to be set for all scopes between the root and the current scope. Nils -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
Ugh ! It gets messier. I'm beginning to understand why it is the way it is. The cmake developers have probably already been round this loop and decided it wasn't worth the effort :-) On 1 May 2014 19:41, Nils Gladitz nilsglad...@gmail.com wrote: On 01.05.2014 20:38, Glenn Coombs wrote: Okay, I think I understand what you're saying. Variables set in a CMakeLists.txt file added by add_subdirectory are only visible in that CMakeLists.txt and any further ones it adds via add_subdirectory. The higher level CMakeLists.txt files would not have the necessary visibility, hence the need to cache the project source directory variable. To make it behave consistently it would be necessary for cmake to be able to set a variable in the scope of the top level CMakeLists.txt. Similar to the PARENT_SCOPE that the set() command already has, something like set(foo_SOURCE_PROJECT path/to/source ROOT_SCOPE). I suspect that the reason cmake is caching these variable is because the set() command doesn't have a ROOT_SCOPE ability and using cache variables was the easiest way to simulate that. And we have to live with the unfortunate side effect that the cached variables don't exist on the first run but do on subsequent runs. I don't think it would be sufficient to set it in the root scope either since I think each scope has its own copy of the variable. It would have to be set for all scopes between the root and the current scope. Nils -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
On 2014-04-23 14:18, Glenn Coombs wrote: Are the [Project name]_SOURCE_DIR variables being automatically stored in the cmake cache? Running 'grep _SOURCE_DIR CMakeCache.txt' would answer this question. (And yes, they are.) -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
I'm using cmake version 2.8.12.1 and have just encountered an issue with my
cmake setup where I was using the [Project name]_SOURCE_DIR variable in an
include_directories command and it was being ignored. In my top level
CMakeLists.txt I had:
project(blah)
add_subdirectory(foo)
add_subdirectory(...)
...
add_subdirectory(bar)
and in the CMakeLists.txt in the foo directory:
include_directories(${bar_SOURCE_DIR})
The project failed to build because the foo project couldn't find header
files located in the bar project source directory. The fix was to move the
add_subdirectory(bar) before the add_subdirectory(foo) command. The
interesting thing is that this setup only caused an error when doing a
clean build from scratch. It looks like it only fails after a clean start
and a single run of the cmake generator. If you run cmake-gui and
configure more than once, as you may well do if you need to set some
options, then it appears to get the correct value for ${bar_SOURCE_DIR}.
Are the [Project name]_SOURCE_DIR variables being automatically stored in
the cmake cache, as that would explain what I am seeing ? I would expect
the above scenario to consistently fail every time due to the missing
header files. Having it only fail the first time and then work after
subsequent configure/generate steps is confusing. Is this a bug, or are
there occasions when this is desirable behaviour ?
--
Glenn
P.S. In an ideal world I'd like to see the expansion of the [Project
name]_SOURCE_DIR variables be deferred until after all the CMakeLists.txt
files have been read in so that the order doesn't matter, but I'm guessing
that isn't going to happen :-)
--
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://www.cmake.org/mailman/listinfo/cmake
