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
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
