[cmake-developers] Roadmap to CMake 3.0

[Alexander Neundorf]

On Friday 11 October 2013, Brad King wrote:
> Hi Folks,
> 
> I think the time has come for a major version number bump to go with
> some major updates.  I propose to skip preparing 2.8.13 in 'master'
> and go straight to 3.0.0.  If necessary it would still be possible
> to support 2.8.12.1+ or 2.8.13+ maintenance releases by basing topics
> on older versions instead of master.
> 
> The reasons we've been on 2.8.x for so long are:
> 
> * 2.9.<date> was taken by CVS development versions when the 2.8.x
>   series started just before conversion to Git.
> 
> * 2.10 cannot be used because CMAKE_VERSION and if(. VERSION_LESS .)
>   did not exist prior to CMake 2.6.3 so old code does floating-point
>   comparisons of version numbers like 2.4, and 2.10 will look like
>   2.1 to such code.  This will not be a problem for 3.x versions.
> 
> * 3.x has been reserved for the future time when we have some major
>   changes underway.  This time has come.
> 
> Potential changes motivating a major version number bump include:
> 
> * New documentation system using reStructuredText and Sphinx.  This
>   will not be 100% workflow-compatible with the old documentation
>   system as discussed in the relevant thread.
> 
> * Policy CMP0026 changes behavior of the commonly-used LOCATION target
>   property in favor of generator expressions.  This is needed to move
>   more logic to generate-time where it belongs.  Steve can explain in
>   more detail if anyone wants.  A draft of this is already in 'next'.
> 
> * New quoting syntax: Lua-style long-brackets.  Quoting opens with
>   "[" followed by zero or more "=" followed by "[" and closes with
>   "]" followed by the same number of "=" followed by "]".  No
>   evaluation is performed on the content.  It is very nice for
>   inline literal content.
> 
>   This is an incompatible change because unquoted arguments starting
>   in "[[", "[=[", etc. will now be treated as opening long brackets
>   (expecting a matching close bracket) instead of unquoted arguments.
>   CMake 2.8.12 added a warning for this case.  This happens at the
>   parsing stage so we cannot use a policy for it.  Fortunately this
>   should be a rare occurrence in practice, but still should come
>   with a major version number bump.
> 
> * The "cmake --build" tool should share stdout and stderr with the
>   caller instead of separately buffering/merging them.  This will be
>   an incompatible change possibly affecting user scripts in ways that
>   should only come with a major version bump and release notes.
> 
> * New policies to disable old commands that require significant
>   amounts of C++ code to be kept around just to support them.
>   These include (but may not be limited to):
> 
>   - exec_program: replaced by execute_process
>   - export_library_dependencies: replaced by export()/install(EXPORT)
>   - load_command: replaced by macros and functions; does not work
>     when the toolchain does not match the CMake binary anyway
>   - output_required_files: obscure
> 
> * Drop the "cmake -i" wizard mode.  This has long been replaced by
>   ccmake, cmake-gui, or just cmake with -D options.
> 
> * Drop implementation of compatibility modes with CMake versions
>   prior to 2.4.0 which is now over 7 years old.

Would this also be a chance to change the if( STREQUAL ) string vs. variable 
lookup rules ?
Hmm, simply changing the behaviour would most probably break a lot of stuff.
Maybe with a policy ?
I.e. never do variable lookup, always just compare the strings, and maybe warn 
if there is a variable named like one of the strings ?
Or introduce the whole set of comparison operators ("==", "<", etc.), which 
would then never do variable lookup, and "deprecate" the current ones ?

Alex