[cmake-developers] Preparing for CMake 3.0.0-rc1

Matthew Woehlke mw_triad at users.sourceforge.net
Mon Jan 27 17:59:31 EST 2014

On 2014-01-27 16:58, Stephen Kelly wrote:
> Though I still don't like the behavior in the topic with project() commands
> without a specified VERSION and the
> all the complexity is needed.
>  From what I understand, the reason it was added is related to using
> add_subdirectory to add a self-contained/standalone project to host
> buildsystem. These VERSION variables are not alone in 'conflict
> possibilities' in that case. The 'sub-project' already may not use

Huh? Of course it can; it just needs to know that CMAKE_SOURCE_DIR != 
the sub-project's source dir. (In fact, testing this is probably the 
canonical way to determine if a project is embedded or not.)

The reason for handling project(VERSION) specially was so that the 
parent project can start using project(VERSION) but arrange that the 
behavior of project() won't suddenly change within the subproject, in 
case the subproject is already using variables with the same names as 
the version variables that project() would otherwise newly unset.

> and there are other constraints which we don't have
> listed/documented anywhere. There are existing reasons why ExternalProject
> should be used instead of add_subdirectory in such cases. These VERSION
> variables can just be another reason. The 'host' buildsystem would itself
> have to set the VERSION, so it can ensure that that actually works with its
> sub-directory projects.
> There should not be special behavior with these VERSION variables. Or if
> there really should be, the reason should be in the commit message.

I haven't looked at the actual commits; it may be their messages could 
be improved. I don't think it's so hard to avoid gratuitous breakage of 
nested projects however that it isn't worth doing so.

And in fact, I believe it isn't just nested projects that would break, 
but any project that was using the same variable names as 
project(VERSION) would set... We really don't want the behavior change 
that, without any modification to CMakeLists.txt, project() suddenly 
unsets variables. (I suppose there is a policy argument that could be 
instead gives us reasonable behavior implicitly, and allows for projects 
nesting other projects to avoid breaking the nested projects.)

That said, I'm assuming the behavior is as described in 
and preceding, and NOT as described in 
which is overkill.


More information about the cmake-developers mailing list