On 2014-01-28 11:16, Jean-Christophe Fillion-Robin wrote:
On Tue, Jan 28, 2014 at 9:10 AM, Brad King wrote:
So our options are
(1) Design new behavior in a way that requires a change to the
project to activate.
(2) Add a policy. The policy should only trigger when the
project() command is about to unset a PROJECT_VERSION
variable that was set by user code and not by a previous
project() command.
I would vote for (2), that way people using the latest and greatest of
CMake won't have to enable any variable and it will work out of the box.
This is also the case with (1), but (1) has the advantage that a project
wishing to use the new feature that also contains a nested subproject
that is not aware of (and would be broken by) the new feature can avoid
breaking its nested project.
Note that (as I understand it, anyway) the "change to activate" in (1)
is using project(VERSION).
IOW, with (1), until you either use project(VERSION) or manually set the
variable (though it's hard to imagine why you would ever need to do the
latter), you get the old behavior. Once you do either, you get the new
behavior... unless you subsequently unset the variable, in which case
you go back to the old behavior. (Also see Brad's reply.)
I suppose with (2), requiring CMake >= 3.0 would give you the new
behavior unless you override the policy. I'm not in favor of this as I
don't see any significant advantage over (1), but it can break nested
projects that aren't expecting the new behavior. (If someone can present
a strong reason why a policy would be better, that might change my mind.)
--
Matthew
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
