On Wed, Jun 17, 2009 at 09:07:19AM -0400, Brad King wrote: > # Top/CMakeLists.txt > add_subdirectory(A) > add_subdirectory(B) > > # A/CMakeLists.txt > set(foo 1) > add_subdirectory(../C ../C) > > # B/CMakeLists.txt > set(foo 0) > add_subdirectory(../C ../C) > > # C/CMakeLists.txt > if(foo) > # Which of these > else(foo) > # two options? > endif(foo) > > Switching A and B on/off or switching their order can lead to > surprising changes in behavior.
Agreed, but we obviously don't do anything like this. > Even if it were a policy, any project that tries to do this would get > the warning. Yes, it could temporarily avoid the warning by setting > the policy to OLD, but it should *still* be updated to the NEW > behavior! Again, policies are not used for choosing among desirable > behaviors. I don't understand this. Are we debating semantics (whether the multiple-add_subdirectory() behavior is "desirable")? Are policies to be used for choosing between undesirable, now-deprecated behavior and desirable behavior? It seems to me that 2.6.4 introduced some changed/improved some behavior. CMake policies are designed to help insulate CMake users from changes in behavior. Because I cannot insulate myself from this change, I am stuck between not upgrading to the latest CMake and rewriting my scripts. Isn't *this* the kind of thing policies are designed to address? Thanks, tyler _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
