[cmake-developers] RFC: add version to project() call

[Matthew Woehlke]

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