[cmake-developers] Preparing for CMake 3.0.0-rc1

[Matthew Woehlke]

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
> CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND variable etc. I don't see why
> 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
> CMAKE_SOURCE_DIR

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 
made there, but using CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND 
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 
http://permalink.gmane.org/gmane.comp.programming.tools.cmake.devel/9108 
and preceding, and NOT as described in 
http://permalink.gmane.org/gmane.comp.programming.tools.cmake.devel/9113 
which is overkill.

-- 
Matthew