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

[Alexander Neundorf]

On Wednesday 15 January 2014, Alexander Neundorf wrote:
> On Wednesday 15 January 2014, Matthew Woehlke wrote:
> > On 2014-01-14 18:00, Alexander Neundorf wrote:
> > > On Tuesday 14 January 2014, Matthew Woehlke wrote:
> > >> 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.
> > 
> > Exactly. I wanted to point it out, but as that's probably unusual, I
> > would be okay ignoring that case.
> > 
> > > If it would be
> > > 
> > > B/CMakeLists.txt:
> > > 
> > > 
> > > project(Bar)
> > > set(PROJECT_VERSION "4.5.6")
> > > 
> > > everything is fine.
> > 
> > ...until B/C/CMakeLists.txt also calls project() :-). Basically, you
> > (can) get into trouble if you "update" your project to use
> > project(VERSION) and also have an "external" sub-project that tries to
> > use PROJECT_VERSION. However, as much as folks¹ occasionally bleat about
> > this use case (having an embedded "external" project), I suspect it's
> > not actually very common², and anyway there is only a problem when the
> > sub-project *also* uses PROJECT_VERSION (which I suspect is also rare in
> > general, and more so the intersection of the two).
> > 
> > Again, given the above, I've no objection to breaking that case, which
> > may well only exist in the hypothetical sense with no 'in the wild'
> > instances actually existing.
> 
> And, to actually produce the breakage, at some place the VERSION argument
> must have been added.
> With the current state of my branch, this could be worked around by
> unsetting the guard variable:
> 
> 
> project(Foo VERSION 1.2.3)
> ....
> 
> unset(CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND)
> add_subdir(B)
> 
> This way B would be protected from that change in behaviour.

I could also add more logic, to try to detect if PROJECT_VERSION has been set 
manually, e.g. project() could reset PROJECT_VERSION only if it has the same 
value as ${${ParentProjectName}_VERSION}. Then it would only break if there 
was a manual set(PROJECT_VERSION ...) before a project() call without VERSION, 
and if that manually set version was the same as the version in the "parent 
project".

Or, maybe, project() without VERSION should simply NOT clear PROJECT_VERSION.
Then it may be a somewhat inconsistent or not ideal behaviour, but OTOH there 
is zero chance for breaking an existing build by adding a VERSION somewhere.

Alex