[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

What's the purpose of the "=" between the square 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.

Yes, sounds old enough.

I'd like to remove the --find-package mode, which was my attempt to make cmake 
packages easier to use by non-cmake projects.
The idea was that you can use cmake --find-package JPEG similar to pkg-config, 
i.e. call it from handwritten makefiles or autoconf, and it prints the include 
dirs, link dirs and libs to link to stdout so they are handed as options to 
the compiler.
To do that, it is/was relying on a set of standard variables (Foo_LIBRARIES, 
Foo_INCLUDE_DIRS and some slight variations) being set by Find-modules/Config 
files.
Since it was recently decided that it is fine to recommend using imported 
target names directly and not to set the standard variables anymore, I don't 
see how I could improve this in the future.
So instead I'd like to remove it instead of keeping a somewhat broken, 
sometimes working feature around. which is not used widely.

Alex