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
