[cmake-developers] Roadmap to CMake 3.0
Brad King
brad.king at kitware.com
Fri Oct 11 15:10:08 EDT 2013
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.
Comments?
-Brad
More information about the cmake-developers
mailing list