Thank you very much
> Am 25.02.2015 um 15:12 schrieb Robert Maynard <[email protected]>: > > Hi Roman, > > We do attach the short-log of all changes made between each RC version > to the bottom of the annoucement. But here are the changes plus the > git SHA1's for each ( produced with git log --no-merges --oneline > v3.2.0-rc1..v3.2.0-rc2) > > 99575c9 CMake 3.2.0-rc2 > b4005a3 FindCurses: Drop unused check for cbreak in tinfo library > a41d621 bootstrap: Add --(no-)system-jsoncpp options > a576844 FindJsonCpp: Drop new module due to upstream jsoncpp providing package > 1ade687 cmake-gui: Reset generator platform and toolset on configure (#15411) > 7e6608f Utilities/Release: Build OS X and Win binaries without OpenSSL > bce4e20 FindJNI: Add arch-specific library dir for JDK 9 layout (#15408) > 6d19ef9 Help: In 3.2 relnotes move OpenGL/X11 to deprecated/removed section > 029d38f Help: Revise configure_file documentation (#15403) > >> On Wed, Feb 25, 2015 at 9:07 AM, Roman Wüger <[email protected]> wrote: >> Hello Robert, >> >> is there a list which showing the changes between rc1 and rc2, to test such >> things explicitly? >> >> Regards >> Roman >> >> >>> Am 24.02.2015 um 16:01 schrieb Robert Maynard <[email protected]>: >>> >>> I am proud to announce the CMake 3.2 second release candidate. >>> >>> Sources and binaries are available at: >>> http://www.cmake.org/download/ >>> http://www.cmake.org/files/v3.2/?C=M;O=D >>> >>> Documentation is available at: >>> http://www.cmake.org/cmake/help/v3.2 >>> >>> Release notes appear below and are also published at >>> http://www.cmake.org/cmake/help/v3.2/release/3.2.html >>> Some of the more significant features of CMake 3.2 are: >>> >>> * CMake learned to support unicode characters *encoded as UTF-8* on >>> Windows. This was already supported on platforms whose system APIs >>> accept UTF-8 encoded strings. Unicode characters may now be used in >>> CMake code, paths to source files, configured files such as ".h.in" >>> files, and other files read and written by CMake. Note that because >>> CMake interoperates with many other tools, there may still be some >>> limitations when using certain unicode characters. >>> >>> * The "Compile Features" functionality is now aware of features >>> supported by more compilers, including: >>> >>> * Apple Clang ("AppleClang") for Xcode versions 4.4 though 6.1. >>> >>> * GNU compiler versions 4.4 through 5.0 on UNIX and Apple ("GNU"). >>> >>> * Microsoft Visual Studio ("MSVC") for versions 2010 through 2015. >>> >>> * Oracle SolarisStudio ("SunPro") version 12.4. >>> >>> * The "add_custom_command()" and "add_custom_target()" commands >>> learned a new "BYPRODUCTS" option to specify files produced as side >>> effects of the custom commands. These are not outputs because they >>> do not always have to be newer than inputs. >>> >>> * The "file(GENERATE)" command can now generate files which are used >>> as source files for buildsystem targets. Generated files >>> automatically get their "GENERATED" property set to "TRUE". >>> >>> Deprecated and Removed Features: >>> >>> * Files written in the "cmake-language(7)", such as "CMakeLists.txt" >>> or "*.cmake" files, are now expected to be encoded as UTF-8. If >>> files are already ASCII, they will be compatible. If files were in >>> a different encoding, including Latin 1, they will need to be >>> converted. >>> >>> * The "FindOpenGL" module no longer explicitly searches for any >>> dependency on X11 libraries with the "FindX11" module. Such >>> dependencies should not need to be explicit. Applications using X11 >>> APIs themselves should find and link to X11 libraries explicitly. >>> >>> >>> CMake 3.2 Release Notes >>> *********************** >>> >>> Changes made since CMake 3.1 include the following. >>> >>> >>> New Features >>> ============ >>> >>> >>> Syntax >>> ------ >>> >>> * CMake learned to support unicode characters *encoded as UTF-8* on >>> Windows. This was already supported on platforms whose system APIs >>> accept UTF-8 encoded strings. Unicode characters may now be used in >>> CMake code, paths to source files, configured files such as ".h.in" >>> files, and other files read and written by CMake. Note that because >>> CMake interoperates with many other tools, there may still be some >>> limitations when using certain unicode characters. >>> >>> >>> Commands >>> -------- >>> >>> * The "add_custom_command()" and "add_custom_target()" commands >>> learned a new "BYPRODUCTS" option to specify files produced as side >>> effects of the custom commands. These are not outputs because they >>> do not always have to be newer than inputs. >>> >>> * The "add_custom_command()" and "add_custom_target()" commands >>> learned a new "USES_TERMINAL" option to request that the command be >>> given direct access to the terminal if possible. The "Ninja" >>> generator will places such commands in the "console" "pool". Build >>> targets provided by CMake that are meant for individual interactive >>> use, such as "install", are now placed in this pool. >>> >>> * A new "continue()" command was added that can be called inside >>> loop contexts to end the current iteration and start the next one at >>> the top of the loop block. >>> >>> * The "file(LOCK)" subcommand was created to allow CMake processes >>> to synchronize through file and directory locks. >>> >>> * The "file(STRINGS)" now supports UTF-16LE, UTF-16BE, UTF-32LE, >>> UTF- 32BE as "ENCODING" options. >>> >>> * The "install(EXPORT)" command now works with an absolute >>> "DESTINATION" even if targets in the export set are installed with a >>> destination or *usage requirements* specified relative to the >>> install prefix. The value of the "CMAKE_INSTALL_PREFIX" variable is >>> hard-coded into the installed export file as the base for relative >>> references. >>> >>> * The "try_compile()" command source file signature now honors link >>> flags (e.g. "CMAKE_EXE_LINKER_FLAGS") in the generated test project. >>> See policy "CMP0056". >>> >>> * The "try_run()" command learned to honor the "LINK_LIBRARIES" >>> option just as "try_compile()" already does. >>> >>> * The "file(GENERATE)" command now generates the output file with >>> the same permissions as the input file if set. >>> >>> * The "file(GENERATE)" command can now generate files which are used >>> as source files for buildsystem targets. Generated files >>> automatically get their "GENERATED" property set to "TRUE". >>> >>> >>> Variables >>> --------- >>> >>> * The "CMAKE_MATCH_COUNT" variable was introduced to record the >>> number of matches made in the last regular expression matched in an >>> "if()" command or a "string()" command. >>> >>> >>> Properties >>> ---------- >>> >>> * An "ANDROID_API_MIN" target property was introduced to specify the >>> minimum version to be targeted by the toolchain. >>> >>> * A "VS_SHADER_FLAGS" source file property was added to specify >>> additional shader flags to ".hlsl" files, for the Visual Studio >>> generators. >>> >>> >>> Modules >>> ------- >>> >>> * The "ExternalData" module learned to support *Custom Fetch >>> Scripts*. This allows projects to specify custom ".cmake" scripts >>> for fetching data objects during the build. >>> >>> * The "ExternalProject" module learned options to create independent >>> external project step targets that do not depend on the builtin >>> steps. >>> >>> * The "ExternalProject" module "ExternalProject_Add()" command >>> learned a new "CMAKE_CACHE_DEFAULT_ARGS" option to initialize cache >>> values in the external project without setting them on future >>> builds. >>> >>> * The "ExternalProject" module "ExternalProject_Add()" command >>> learned a new "TEST_EXCLUDE_FROM_MAIN" option to exclude tests from >>> the main build. >>> >>> * The "ExternalProject" module "ExternalProject_Add()" command >>> learned a new "UPDATE_DISCONNECTED" option to avoid automatically >>> updating the source tree checkout from version control. >>> >>> * The "FindCUDA" module learned about the "cusolver" library in CUDA >>> 7.0. >>> >>> * The "FindGit" module learned to find the "git" command-line tool >>> that comes with GitHub for Windows installed in user home >>> directories. >>> >>> * A "FindGSL" module was introduced to find the GNU Scientific >>> Library. >>> >>> * A "FindIntl" module was introduced to find the Gettext "libintl" >>> library. >>> >>> * The "FindLATEX" module learned to support components. >>> >>> * The "FindMPI" module learned to find MS-MPI on Windows. >>> >>> * The "FindOpenSSL" module now reports "crypto" and "ssl" libraries >>> separately in "OPENSSL_CRYPTO_LIBRARY" and "OPENSSL_SSL_LIBRARY", >>> respectively, to allow applications to link to one without the >>> other. >>> >>> * The "WriteCompilerDetectionHeader" module learned to create a >>> define for portability of the "cxx_thread_local" feature. The define >>> expands to either the C++11 "thread_local" keyword, or a pre- >>> standardization compiler-specific equivalent, as appropriate. >>> >>> * The "WriteCompilerDetectionHeader" module learned to create >>> multiple output files per compiler and per language, instead of >>> creating one large file. >>> >>> >>> CTest >>> ----- >>> >>> * The "ctest_coverage()" command learned to support Delphi coverage. >>> >>> * The "ctest_coverage()" command learned to support Javascript >>> coverage. >>> >>> * The "CTestCoverageCollectGCOV" module was introduced as an >>> alternative to the "ctest_coverage()" command for collecting "gcov" >>> results for submission to CDash. >>> >>> >>> CPack >>> ----- >>> >>> * The "CPackRPM" module learned options to set per-component >>> descriptions and summaries. See the >>> "CPACK_RPM_<component>_PACKAGE_DESCRIPTION" and >>> "CPACK_RPM_<component>_PACKAGE_SUMMARY" variables. >>> >>> * The "CPackRPM" module learned options to specify requirements for >>> pre- and post-install scripts. See the >>> "CPACK_RPM_PACKAGE_REQUIRES_PRE" and >>> "CPACK_RPM_PACKAGE_REQUIRES_POST" variables. >>> >>> * The "CPackRPM" module learned options to specify requirements for >>> pre- and post-uninstall scripts. See the >>> "CPACK_RPM_PACKAGE_REQUIRES_PREUN" and >>> "CPACK_RPM_PACKAGE_REQUIRES_POSTUN" variables. >>> >>> * The "CPackRPM" module learned a new >>> "CPACK_RPM_<COMPONENT>_PACKAGE_PREFIX" variable to specify a >>> component-specific value to use instead of >>> "CPACK_PACKAGING_INSTALL_PREFIX". >>> >>> * The "CPackRPM" module learned a new "CPACK_RPM_RELOCATION_PATHS" >>> variable to specify multiple relocation prefixes for a single rpm >>> package. >>> >>> >>> Other >>> ----- >>> >>> * The "cmake(1)" "-E tar" command now supports creating >>> ".xz"-compressed archives with the "J" flag. >>> >>> * The "cmake(1)" "-E tar" command learned a new "--files- >>> from=<file>" option to specify file names using lines in a file to >>> overcome command-line length limits. >>> >>> * The "cmake(1)" "-E tar" command learned a new "--mtime=<date>" >>> option to specify the modification time recorded in tarball entries. >>> >>> * The "Compile Features" functionality is now aware of features >>> supported by more compilers, including: >>> >>> * Apple Clang ("AppleClang") for Xcode versions 4.4 though 6.1. >>> >>> * GNU compiler versions 4.4 through 5.0 on UNIX and Apple ("GNU"). >>> >>> * Microsoft Visual Studio ("MSVC") for versions 2010 through 2015. >>> >>> * Oracle SolarisStudio ("SunPro") version 12.4. >>> >>> * The *AUTORCC* feature now tracks files listed in ".qrc" files as >>> dependencies. If an input file to the "rcc" tool is changed, the >>> tool is automatically re-run. >>> >>> >>> New Diagnostics >>> =============== >>> >>> * The "break()" command now rejects calls outside of a loop context >>> or that pass arguments to the command. See policy "CMP0055". >>> >>> >>> Deprecated and Removed Features >>> =============================== >>> >>> * Files written in the "cmake-language(7)", such as "CMakeLists.txt" >>> or "*.cmake" files, are now expected to be encoded as UTF-8. If >>> files are already ASCII, they will be compatible. If files were in >>> a different encoding, including Latin 1, they will need to be >>> converted. >>> >>> * The "FindOpenGL" module no longer explicitly searches for any >>> dependency on X11 libraries with the "FindX11" module. Such >>> dependencies should not need to be explicit. Applications using X11 >>> APIs themselves should find and link to X11 libraries explicitly. >>> >>> * The implementation of CMake now relies on some C++ compiler >>> features which are not supported by some older compilers. As a >>> result, those old compilers can no longer be used to build CMake >>> itself. CMake continues to be able to generate Makefiles and >>> project files for users of those old compilers however. Compilers >>> known to no longer be capable of building CMake are: >>> >>> * Visual Studio 6 and 7.0 -- superseded by VisualStudio 7.1 and >>> newer. >>> >>> * GCC 2.95 -- superseded by GCC 3 and newer compilers. >>> >>> * Borland compilers -- superseded by other Windows compilers. >>> >>> * Compaq compilers -- superseded by other compilers. >>> >>> * SGI compilers -- IRIX was dropped as a host platform. >>> >>> >>> Other Changes >>> ============= >>> >>> * On Windows and OS X, commands supporting network communication via >>> "https", such as "file(DOWNLOAD)", "file(UPLOAD)", and >>> "ctest_submit()", now support SSL/TLS even when CMake is not built >>> against OpenSSL. The Windows or OS X native SSL/TLS implementation >>> is used by default. OS-configured certificate authorities will be >>> trusted automatically. >>> >>> On other platforms, when CMake is built with OpenSSL, these commands >>> now search for OS-configured certificate authorities in a few "/etc" >>> paths to be trusted automatically. >>> >>> * On OS X with Makefile and Ninja generators, when a compiler is >>> found in "/usr/bin" it is now mapped to the corresponding compiler >>> inside the Xcode application folder, if any. This allows such build >>> trees to continue to work with their original compiler even when >>> "xcode- select" switches to a different Xcode installation. >>> >>> * The Visual Studio generators now write solution and project files >>> in UTF-8 instead of Windows-1252. Windows-1252 supported Latin 1 >>> languages such as those found in North and South America and Western >>> Europe. With UTF-8, additional languages are now supported. >>> >>> * The "Xcode" generator no longer requires a value for the >>> "CMAKE_MAKE_PROGRAM" variable to be located up front. It now locates >>> "xcodebuild" when needed at build time. >>> >>> * When building CMake itself using SolarisStudio 12, the default >>> "libCStd" standard library is not sufficient to build CMake. The >>> SolarisStudio distribution supports compiler options to use >>> "STLPort4" or "libstdc++". An appropriate option to select the >>> standard library is now added automatically when building CMake with >>> SolarisStudio compilers. >>> >>> ------------------------------------------------------------------- >>> >>> Changes made since CMake 3.1.0-rc1: >>> >>> Brad King (8): >>> Help: Revise configure_file documentation (#15403) >>> Help: In 3.2 relnotes move OpenGL/X11 to deprecated/removed section >>> Utilities/Release: Build OS X and Win binaries without OpenSSL >>> cmake-gui: Reset generator platform and toolset on configure (#15411) >>> FindJsonCpp: Drop new module due to upstream jsoncpp providing package >>> bootstrap: Add --(no-)system-jsoncpp options >>> FindCurses: Drop unused check for cbreak in tinfo library >>> CMake 3.2.0-rc2 >>> >>> Tiago Stürmer Daitx (1): >>> FindJNI: Add arch-specific library dir for JDK 9 layout (#15408) >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
