On 2014-01-14 10:37, Brad King wrote:
On 01/13/2014 01:38 PM, Alexander Neundorf wrote:
does this require a policy now ?
Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a
project(Foo)
call in a subdir, which would now unset Foo_VERSION_MAJOR.
The same for PROJECT_VERSION_MAJOR, but this is maybe less likely.
I don't think project(Foo) needs to affect Foo_VERSION_* when no
VERSION argument is given (but should handle empty VERSION "").
It should still handle PROJECT_VERSION_* to ensure consistency
with PROJECT_NAME. That may need a policy, but it will be tricky
because we need to know if the value came from a previous project()
call or a user set() in order to know when to trigger compatibility.
Perhaps "project(... VERSION ...)" can set some cmMakefile variable
internally that says the project knows about versions so it is okay
project(Foo) calls to unset them in subdirs. Then we won't need any
policy because there is no change in behavior without modifying the
project to add at least one VERSION to a project() command.
While that sounds good for 99.9% of cases, what about the case of
project A that includes project B, where B is not updated, but A decides
to start using project(...VERSION...). Now if B was using
PROJECT_VERSION internally, it is broken. (Note that I'm implying that B
is e.g. a separate repository that may not be "as easy to update/fix as A".)
That's an edge case though... not sure it's worth worrying about, but
just saying...
@Daniel, there is a CMAKE_PROJECT_NAME? I've always used just
PROJECT_NAME... (Is PROJECT_NAME deprecated?) Anyway, while *hopefully*
no one is setting e.g. CMAKE_PROJECT_VERSION there's still risk that
they are.
--
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
