[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