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

[Alexander Neundorf]

On Tuesday 14 January 2014, Matthew Woehlke wrote:
> 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".)

You mean
CMakeLists.txt:

project(Foo VERSION 1.2.3)

...

add_subdir(B)

B/CMakeLists.txt:

set(PROJECT_VERSION "4.5.6")
project(Bar)


Indeed.
In that case, PROJECT_VERSION will be unset afterwards.

If it would be 

B/CMakeLists.txt:


project(Bar)
set(PROJECT_VERSION "4.5.6")

everything is fine.

Alex