Tyler Roscoe wrote:
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?
Replace the word "desirable" with "supported". One day we will release
a CMake that does not implement the OLD behavior for a given policy.
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?
Yes, it is exactly what policies are meant to do. As I said in my
previous post we didn't think any real project could be using the
behavior and thought this change was just a bug fix to help new
projects avoid subtle problems. That's why we didn't bother with
a policy.
Consider the missing policy a bug. We can fix the bug by adding
a policy in 2.6.5. That doesn't mean you can just set it to OLD
and never change your project though. A future CMake (say 3.0)
won't support it.
-Brad
_______________________________________________
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
