[ANNOUNCE] CMake 3.8.0-rc1 now ready for testing!

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[ANNOUNCE] CMake 3.8.0-rc1 now ready for testing!

Robert Maynard
I am proud to announce the first CMake 3.8 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.8

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.8/release/3.8.html

Some of the more significant changes in CMake 3.8 are:

* CMake now supports "CSharp" (C#) as a first-class language. It is
  currently supported by the Visual Studio Generators for VS 2010
  and above.

* CMake now supports "CUDA" as a first-class language. It is
  currently supported by the Makefile Generators and the
  "Ninja" generator on Linux, macOS, and Windows. Support for the
  Visual Studio IDE is under development but not included in this
  release.

* The "Compile Features" functionality now offers meta-features that
  request compiler modes for specific language standard levels (e.g.
  "cxx_std_11").  See "CMAKE_C_KNOWN_FEATURES" and
  "CMAKE_CXX_KNOWN_FEATURES".

* The "Compile Features" functionality is now aware of C++ 17.  No
  specific features are yet enumerated besides the "cxx_std_17" meta-
  feature.

* The Visual Studio Generators for VS 2013 and above learned to
  support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value
  (e.g.  via the "cmake(1)" "-T" option) to request use of a VS 64-bit
  toolchain on 64-bit hosts.

* The Visual Studio Generators learned to treat files passed to
  "target_link_libraries()" whose names end in ".targets" as MSBuild
  "targets" files to be imported into generated project files.

* The "try_compile()" command source file signature gained new
  options to specify the language standard to use in the generated
  test project.

* The "try_compile()" command source file signature now honors
  language standard variables like "CMAKE_CXX_STANDARD". See policy
  "CMP0067".

* A "BUILD_RPATH" target property and corresponding
  "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH"
  locations to be added to binaries in the build tree.

* The "COMPILE_FLAGS" source file property learned to support
  "generator expressions".

* A new generator expression "$<IF:cond,true-value,false-value>" was
  added. It resolves to the true-value if the condition is "1" and
  resolves to the false-value if the condition is "0".

* The "Compile Features" functionality is now aware of features
  supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX
  and Windows platforms.

* The Visual Studio Generators for VS 2010 and above now place per-
  source file flags after target-wide flags when they are classified
  as raw flags with no project file setting ("AdditionalOptions").
  This behavior is more consistent with the ordering of flags produced
  by other generators, and allows flags on more-specific properties
  (per-source) to override those on more general ones (per-target).

* The precompiled Windows binary MSI package provided on "cmake.org"
  now records the installation directory in the Windows Registry under
  the key "HKLM\Software\Kitware\CMake" with a value named
  "InstallDir".

CMake 3.8 Release Notes
***********************

Changes made since CMake 3.7 include the following.


New Features
============


Languages
---------


C#
~~

* CMake learned to support "CSharp" (C#) as a first-class language
  that can be enabled via the "project()" and "enable_language()"
  commands.  It is currently supported by the Visual Studio Generators
  for VS 2010 and above.

  C# assemblies and programs can be added just like common C++ targets
  using the "add_library()" and "add_executable()" commands.
  References between C# targets in the same source tree may be
  specified by "target_link_libraries()" like for C++.  References to
  system or 3rd-party assemblies may be specified by the target
  properties "VS_DOTNET_REFERENCE_<refname>" and
  "VS_DOTNET_REFERENCES".

* More fine tuning of C# targets may be done using target and source
  file properties.  Specifically the target properties related to
  Visual Studio ("VS_*") are worth a look (for setting toolset
  versions, root namespaces, assembly icons, ...).

* Auto-linking in ".csproj" files: In C#/.NET development with
  Visual Studio there are a number of visual editors used which
  generate code.  Both the generated files and the ones edited with
  the UI are connected in the ".csproj" file using "<DependentUpon>"
  tags.  If CMake finds within a C# project any source file with
  extension ".Designer.cs" or ".xaml.cs", it checks sibling files with
  extension ".xaml", ".settings", ".resx" or ".cs" and establishes the
  dependency connection.


CUDA
~~~~

* CMake learned to support "CUDA" as a first-class language that can
  be enabled via the "project()" and "enable_language()" commands.

* "CUDA" is currently supported by the Makefile Generators and the
  "Ninja" generator on Linux, macOS, and Windows. Support for the
  Visual Studio IDE is under development but not included in this
  release.

* The NVIDIA CUDA Toolkit compiler ("nvcc") is supported.


C & C++
~~~~~~~

* The "Compile Features" functionality now offers meta-features that
  request compiler modes for specific language standard levels (e.g.
  "cxx_std_11").  See "CMAKE_C_KNOWN_FEATURES" and
  "CMAKE_CXX_KNOWN_FEATURES".

* The "Compile Features" functionality is now aware of C++ 17.  No
  specific features are yet enumerated besides the "cxx_std_17" meta-
  feature.

* The "Compile Features" functionality is now aware of the
  availability of C99 in gcc since version 3.4.


Platforms
---------

* A new minimal platform file for "Fuchsia" was added.


Generators
----------

* The "CodeBlocks" extra generator may now be used to generate with
  "NMake Makefiles JOM".

* The Visual Studio Generators for VS 2013 and above learned to
  support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value
  (e.g.  via the "cmake(1)" "-T" option) to request use of a VS 64-bit
  toolchain on 64-bit hosts.

* The Visual Studio Generators learned to treat files passed to
  "target_link_libraries()" whose names end in ".targets" as MSBuild
  "targets" files to be imported into generated project files.


Commands
--------

* The "add_custom_command()" and "add_custom_target()" commands
  learned the option "COMMAND_EXPAND_LISTS" which causes lists in the
  "COMMAND" argument to be expanded, including lists created by
  generator expressions.

* The "execute_process()" command gained an "ENCODING" option to
  specify on Windows which encoding is used for output from child
  process.

* The "math(EXPR)" command gained support for unary "+" and "-"
  operators.

* The "source_group()" command gained "TREE" and "PREFIX" options to
  add groups following source tree directory structure.

* The "string(TIMESTAMP)" command learned to treat "%%" as a way to
  encode plain "%".

* The "string(TIMESTAMP)" command will now honor the
  "SOURCE_DATE_EPOCH" environment variable and use its value instead
  of the current time.

* The "try_compile()" command source file signature gained new
  options to specify the language standard to use in the generated
  test project.

* The "try_compile()" command source file signature now honors
  language standard variables like "CMAKE_CXX_STANDARD". See policy
  "CMP0067".


Variables
---------

* A "CMAKE_CODELITE_USE_TARGETS" variable was added to tell the
  "CodeLite" extra generator to change the generated project to have
  target-centric organization. The "build", "rebuild", and "clean"
  operations within "CodeLite" then work on a selected target rather
  than the whole workspace. (Note that the "Ninja" clean operation on
  a target includes its dependencies, though.)

* The "CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS" variable was added to tell
  the "Sublime Text 2" extra generator to place specified environment
  variables in the generated ".sublime-project".

* The "CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE" variable was added
  to tell the "Sublime Text 2" extra generator whether to exclude the
  build tree from the ".sublime-project" when it is inside the source
  tree.

* A "CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD" variable was added
  to tell Visual Studio Generators for VS 2010 and above to include
  the "PACKAGE" target in the default build, similar to the existing
  "CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" variable for the
  "INSTALL" target.


Properties
----------

* A "BUILD_RPATH" target property and corresponding
  "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH"
  locations to be added to binaries in the build tree.

* The "COMPILE_FLAGS" source file property learned to support
  "generator expressions".

* The "FRAMEWORK" target property may now also be applied to static
  libraries on Apple targets.  It will result in a proper Framework
  but with a static library inside.

* Imported Interface Libraries learned new "IMPORTED_LIBNAME" and
  "IMPORTED_LIBNAME_<CONFIG>" target properties to specify a link
  library name since interface libraries do not build their own
  library files.

* A "<LANG>_CPPLINT" target property and supporting
  "CMAKE_<LANG>_CPPLINT" variable were introduced to tell the Makefile
  Generators and the "Ninja" generator to run the "cpplint" style
  checker along with the compiler for "C" and "CXX" languages.

* A "MANUALLY_ADDED_DEPENDENCIES" target property has been added. It
  provides a read-only list of dependencies that have been added with
  the "add_dependencies()" command.

* The "MAP_IMPORTED_CONFIG_<CONFIG>" target property learned to
  interpret empty list elements as referring to the configuration-less
  imported location specified by "IMPORTED_LOCATION".

* The "NO_SYSTEM_FROM_IMPORTED" target property is now supported on
  Imported Interface Libraries.

* New source file properties "SKIP_AUTOMOC", "SKIP_AUTOUIC",
  "SKIP_AUTORCC", and "SKIP_AUTOGEN" were added to allow source files
  to be excluded from processing by "AUTOMOC", "AUTOUIC", and
  "AUTORCC" target properties.

* A "VS_COPY_TO_OUT_DIR" source file property was added to tell
  Visual Studio Generators for VS 2010 and above whether or not a file
  should e copied to the output directory.

* A "VS_DEBUGGER_WORKING_DIRECTORY" target property was added to
  tell Visual Studio Generators for VS 2010 and above what debugger
  working directory should be set for the target.

* A "VS_DOTNET_REFERENCES_COPY_LOCAL" target property was added to
  specify whether to copy referenced assemblies to the output
  directory.

* A "VS_DOTNET_REFERENCE_<refname>" target property was added to
  tell Visual Studio Generators for VS 2010 and above to add a .NET
  reference with a given hint path.

* A "VS_INCLUDE_IN_VSIX" source file property was added to tell
  Visual Studio Generators for VS 2010 and above whether to include
  the file in a Visual Studio extension package.

* A "VS_RESOURCE_GENERATOR" source file property was added to give
  Visual Studio Generators for VS 2010 and above a setting for the
  resource generator ("C#" only).

* A "VS_USER_PROPS" target property was added to tell Visual Studio
  Generators for VS 2010 and above to use a custom MSBuild user
  ".props" file.

* A "XCODE_EMIT_EFFECTIVE_PLATFORM_NAME" global property was added
  to tell the "Xcode" generator whether to emit the
  "EFFECTIVE_PLATFORM_NAME" variable.  This is useful when building
  with multiple SDKs like "macosx" and "iphoneos" in parallel.

* New "XCODE_PRODUCT_TYPE" and "XCODE_EXPLICIT_FILE_TYPE" target
  properties were created to tell the "Xcode" generator to use custom
  values of the corresponding attributes for a target in the generated
  Xcode project.


Modules
-------

* The "ExternalData" module learned to support multiple content
  links for one data file using different hashes, e.g.
  "img.png.sha256" and "img.png.sha1".  This allows objects to be
  fetched from sources indexed by different hash algorithms.

* The "ExternalProject" module gained the "GIT_PROGRESS" option to
  force Git to show progress when cloning repositories.

* The "ExternalProject" module gained a "GIT_CONFIG" option to pass
  " --config" options to Git when cloning repositories.

* The "FeatureSummary" module "feature_summary()" command now
  accepts a new "QUIET_ON_EMPTY" option that suppresses the output
  when the list of packages that belong to the selected category is
  empty.

* The "FeatureSummary" module "add_feature_info()" command now
  accepts lists of dependencies for deciding whether a feature is
  enabled or not.

* The package types accepted by the "FeatureSummary" module can now
  be tweaked by changing the "FeatureSummary_PKG_TYPES",
  "FeatureSummary_REQUIRED_PKG_TYPES" and
  "FeatureSummary_DEFAULT_PKG_TYPE" global properties.

* The "FindOpenGL" module now provides imported targets "OpenGL::GL"
  and "OpenGL::GLU" when the libraries are found.

* The "UseSWIG" module gained a "swig_add_library" command to give
  more flexibility over the old "swig_add_module" command.

* The "UseSWIG" module "swig_add_source_to_module" command learned a
  new "SWIG_OUTFILE_DIR" option to control the output file location
  ("swig -o").

* The "WriteCompilerDetectionHeader" module gained the
  "ALLOW_UNKNOWN_COMPILERS" and "ALLOW_UNKNOWN_COMPILER_VERSIONS"
  options that allow creation of headers that will work also with
  unknown or old compilers by simply assuming they do not support any
  of the requested features.


CTest
-----

* The "ctest_memcheck()" command gained a "DEFECT_COUNT <var>"
  option to capture the number of memory defects detected.

* The "ctest_memcheck()" command learned to read the location of
  suppressions files for sanitizers from the
  "CTEST_MEMORYCHECK_SUPPRESSIONS_FILE" variable.

* The "ctest_memcheck()" command learned to support "LeakSanitizer"
  independently from "AddressSanitizer".

* The "ctest_update()" command "CDASH_UPLOAD" signature was taught
  to honor the "RETRY_COUNT", "RETRY_DELAY", and "QUIET" options.


CPack
-----

* The "CPackIFWConfigureFile" module was added to define a new
  "cpack_ifw_configure_file()" command to configure file templates
  prepared in QtIFW/SDK/Creator style.

* The "CPackIFW" module "cpack_ifw_configure_component()" and
  "cpack_ifw_configure_component_group()" commands gained a new
  "DEFAULT", "VIRTUAL", "FORCED_INSTALLATION",
  "REQUIRES_ADMIN_RIGHTS", "DISPLAY_NAME", "UPDATE_TEXT",
  "DESCRIPTION", "RELEASE_DATE", "AUTO_DEPEND_ON" and "TRANSLATIONS"
  options to more specific configuration.

* The "CPackIFW" module "cpack_ifw_configure_component()" command
  gained a new "DEPENDENCIES" alias for "DEPENDS" option.

* The "CPackIFW" module "cpack_ifw_configure_component_group()"
  command gained a new "DEPENDS" option. The "DEPENDENCIES" alias also
  added.

* The "CPackIFW" module "cpack_ifw_configure_component()" and
  "cpack_ifw_configure_component_group()" commands "PRIORITY" option
  now is deprecated and will be removed in a future version of CMake.
  Please use new "SORTING_PRIORITY" option instead.

* The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_WATERMARK",
  "CPACK_IFW_PACKAGE_BANNER", "CPACK_IFW_PACKAGE_BACKGROUND",
  "CPACK_IFW_PACKAGE_WIZARD_STYLE",
  "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH",
  "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT", and
  "CPACK_IFW_PACKAGE_TITLE_COLOR" variables to customize a QtIFW
  installer look.

* The "CPackProductBuild" module gained options to sign packages.
  See the variables "CPACK_PRODUCTBUILD_IDENTITY_NAME",
  "CPACK_PRODUCTBUILD_KEYCHAIN_PATH", "CPACK_PKGBUILD_IDENTITY_NAME",
  and "CPACK_PKGBUILD_KEYCHAIN_PATH".

* The "CPackRPM" module learned to omit tags that are not supported
  by provided "rpmbuild" tool. If unsupported tags are set they are
  ignored and a developer warning is printed out.

* The "CPackRPM" module learned to generate main component package
  which forces generation of a rpm for defined component without
  component suffix in filename and package name. See
  "CPACK_RPM_MAIN_COMPONENT" variable.

* The "CPackRPM" module learned to generate a single "debuginfo"
  package on demand even if components packaging is used. See
  "CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE" variable.

* The "CPackRPM" module learned to support multiple directives per
  file when using "CPACK_RPM_USER_FILELIST" variable.


Other
-----

* CMake functionality using cryptographic hashes now supports SHA-3
  algorithms.

* A new generator expression "$<IF:cond,true-value,false-value>" was
  added. It resolves to the true-value if the condition is "1" and
  resolves to the false-value if the condition is "0".


Deprecated and Removed Features
===============================

* The "FeatureSummary" module commands "set_package_info()",
  "set_feature_info()", "print_enabled_features()", and
  "print_disabled_features()" are now deprecated.

* The "UseSWIG" module "swig_add_module" command is now deprecated
  in favor of "swig_add_library".


Other Changes
=============

* If a command specified by the "<LANG>_CLANG_TIDY" target property
  returns non-zero at build time this is now treated as an error
  instead of silently ignored.

* The "ctest_memcheck()" command no longer automatically adds
  "leak_check=1" to the options used by "AddressSanitizer". The
  default behavior of "AddressSanitizer" is to run *LeakSanitizer* to
  check leaks unless "leak_check=0".

* The "ctest_memcheck()" command was fixed to correctly append extra
  sanitizer options read from the
  "CTEST_MEMORYCHECK_SANITIZER_OPTIONS" variable to the environment
  variables used internally by the sanitizers.

* The "FeatureSummary" module "set_package_properties()" command no
  longer forces the package type to "OPTIONAL" when the type is not
  explicitly set.

* The "Compile Features" functionality is now aware of features
  supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX
  and Windows platforms.

* Calls to the "FindPkgConfig" module "pkg_check_modules()" command
  following a successful call learned to re-evaluate the cached values
  for a given prefix after changes to the parameters to the command
  for that prefix.

* When using "AUTOMOC" or "AUTOUIC", generated "moc_*", "*.moc" and
  "ui_*" are placed in the
  "<CMAKE_CURRENT_BINARY_DIR>/<TARGETNAME>_autogen/include" directory
  which is automatically added to the target's "INCLUDE_DIRECTORIES".
  It is therefore not necessary anymore to have
  "CMAKE_CURRENT_BINARY_DIR" in the target's "INCLUDE_DIRECTORIES".

* The "Sublime Text 2" generator no longer runs the native build
  command (e.g. "ninja" or "make") with verbose build output enabled.

* The "try_compile()" command source file signature now honors the
  "CMAKE_WARN_DEPRECATED" variable value in the generated test
  project.

* The Visual Studio Generators for VS 2010 and above now place per-
  source file flags after target-wide flags when they are classified
  as raw flags with no project file setting ("AdditionalOptions").
  This behavior is more consistent with the ordering of flags produced
  by other generators, and allows flags on more-specific properties
  (per-source) to override those on more general ones (per-target).

* The precompiled Windows binary MSI package provided on "cmake.org"
  now records the installation directory in the Windows Registry under
  the key "HKLM\Software\Kitware\CMake" with a value named
  "InstallDir".
--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [ANNOUNCE] CMake 3.8.0-rc1 now ready for testing!

Michael Jackson
Are there any improvements to the cmake -server mode? I am testing the
combination of QtCreator and CMake and there seemed to be an issue where
the list of projects are in Alphabetical order and not in a "top down"
order.
--
Michael A. Jackson
BlueQuartz Software, LLC
[e]: [hidden email]


Robert Maynard wrote:

> I am proud to announce the first CMake 3.8 release candidate.
>    https://cmake.org/download/
>
> Documentation is available at:
>    https://cmake.org/cmake/help/v3.8
>
> Release notes appear below and are also published at
>    https://cmake.org/cmake/help/v3.8/release/3.8.html
>
> Some of the more significant changes in CMake 3.8 are:
>
> * CMake now supports "CSharp" (C#) as a first-class language. It is
>    currently supported by the Visual Studio Generators for VS 2010
>    and above.
>
> * CMake now supports "CUDA" as a first-class language. It is
>    currently supported by the Makefile Generators and the
>    "Ninja" generator on Linux, macOS, and Windows. Support for the
>    Visual Studio IDE is under development but not included in this
>    release.
>
> * The "Compile Features" functionality now offers meta-features that
>    request compiler modes for specific language standard levels (e.g.
>    "cxx_std_11").  See "CMAKE_C_KNOWN_FEATURES" and
>    "CMAKE_CXX_KNOWN_FEATURES".
>
> * The "Compile Features" functionality is now aware of C++ 17.  No
>    specific features are yet enumerated besides the "cxx_std_17" meta-
>    feature.
>
> * The Visual Studio Generators for VS 2013 and above learned to
>    support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value
>    (e.g.  via the "cmake(1)" "-T" option) to request use of a VS 64-bit
>    toolchain on 64-bit hosts.
>
> * The Visual Studio Generators learned to treat files passed to
>    "target_link_libraries()" whose names end in ".targets" as MSBuild
>    "targets" files to be imported into generated project files.
>
> * The "try_compile()" command source file signature gained new
>    options to specify the language standard to use in the generated
>    test project.
>
> * The "try_compile()" command source file signature now honors
>    language standard variables like "CMAKE_CXX_STANDARD". See policy
>    "CMP0067".
>
> * A "BUILD_RPATH" target property and corresponding
>    "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH"
>    locations to be added to binaries in the build tree.
>
> * The "COMPILE_FLAGS" source file property learned to support
>    "generator expressions".
>
> * A new generator expression "$<IF:cond,true-value,false-value>" was
>    added. It resolves to the true-value if the condition is "1" and
>    resolves to the false-value if the condition is "0".
>
> * The "Compile Features" functionality is now aware of features
>    supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX
>    and Windows platforms.
>
> * The Visual Studio Generators for VS 2010 and above now place per-
>    source file flags after target-wide flags when they are classified
>    as raw flags with no project file setting ("AdditionalOptions").
>    This behavior is more consistent with the ordering of flags produced
>    by other generators, and allows flags on more-specific properties
>    (per-source) to override those on more general ones (per-target).
>
> * The precompiled Windows binary MSI package provided on "cmake.org"
>    now records the installation directory in the Windows Registry under
>    the key "HKLM\Software\Kitware\CMake" with a value named
>    "InstallDir".
>
> CMake 3.8 Release Notes
> ***********************
>
> Changes made since CMake 3.7 include the following.
>
>
> New Features
> ============
>
>
> Languages
> ---------
>
>
> C#
> ~~
>
> * CMake learned to support "CSharp" (C#) as a first-class language
>    that can be enabled via the "project()" and "enable_language()"
>    commands.  It is currently supported by the Visual Studio Generators
>    for VS 2010 and above.
>
>    C# assemblies and programs can be added just like common C++ targets
>    using the "add_library()" and "add_executable()" commands.
>    References between C# targets in the same source tree may be
>    specified by "target_link_libraries()" like for C++.  References to
>    system or 3rd-party assemblies may be specified by the target
>    properties "VS_DOTNET_REFERENCE_<refname>" and
>    "VS_DOTNET_REFERENCES".
>
> * More fine tuning of C# targets may be done using target and source
>    file properties.  Specifically the target properties related to
>    Visual Studio ("VS_*") are worth a look (for setting toolset
>    versions, root namespaces, assembly icons, ...).
>
> * Auto-linking in ".csproj" files: In C#/.NET development with
>    Visual Studio there are a number of visual editors used which
>    generate code.  Both the generated files and the ones edited with
>    the UI are connected in the ".csproj" file using "<DependentUpon>"
>    tags.  If CMake finds within a C# project any source file with
>    extension ".Designer.cs" or ".xaml.cs", it checks sibling files with
>    extension ".xaml", ".settings", ".resx" or ".cs" and establishes the
>    dependency connection.
>
>
> CUDA
> ~~~~
>
> * CMake learned to support "CUDA" as a first-class language that can
>    be enabled via the "project()" and "enable_language()" commands.
>
> * "CUDA" is currently supported by the Makefile Generators and the
>    "Ninja" generator on Linux, macOS, and Windows. Support for the
>    Visual Studio IDE is under development but not included in this
>    release.
>
> * The NVIDIA CUDA Toolkit compiler ("nvcc") is supported.
>
>
> C&  C++
> ~~~~~~~
>
> * The "Compile Features" functionality now offers meta-features that
>    request compiler modes for specific language standard levels (e.g.
>    "cxx_std_11").  See "CMAKE_C_KNOWN_FEATURES" and
>    "CMAKE_CXX_KNOWN_FEATURES".
>
> * The "Compile Features" functionality is now aware of C++ 17.  No
>    specific features are yet enumerated besides the "cxx_std_17" meta-
>    feature.
>
> * The "Compile Features" functionality is now aware of the
>    availability of C99 in gcc since version 3.4.
>
>
> Platforms
> ---------
>
> * A new minimal platform file for "Fuchsia" was added.
>
>
> Generators
> ----------
>
> * The "CodeBlocks" extra generator may now be used to generate with
>    "NMake Makefiles JOM".
>
> * The Visual Studio Generators for VS 2013 and above learned to
>    support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value
>    (e.g.  via the "cmake(1)" "-T" option) to request use of a VS 64-bit
>    toolchain on 64-bit hosts.
>
> * The Visual Studio Generators learned to treat files passed to
>    "target_link_libraries()" whose names end in ".targets" as MSBuild
>    "targets" files to be imported into generated project files.
>
>
> Commands
> --------
>
> * The "add_custom_command()" and "add_custom_target()" commands
>    learned the option "COMMAND_EXPAND_LISTS" which causes lists in the
>    "COMMAND" argument to be expanded, including lists created by
>    generator expressions.
>
> * The "execute_process()" command gained an "ENCODING" option to
>    specify on Windows which encoding is used for output from child
>    process.
>
> * The "math(EXPR)" command gained support for unary "+" and "-"
>    operators.
>
> * The "source_group()" command gained "TREE" and "PREFIX" options to
>    add groups following source tree directory structure.
>
> * The "string(TIMESTAMP)" command learned to treat "%%" as a way to
>    encode plain "%".
>
> * The "string(TIMESTAMP)" command will now honor the
>    "SOURCE_DATE_EPOCH" environment variable and use its value instead
>    of the current time.
>
> * The "try_compile()" command source file signature gained new
>    options to specify the language standard to use in the generated
>    test project.
>
> * The "try_compile()" command source file signature now honors
>    language standard variables like "CMAKE_CXX_STANDARD". See policy
>    "CMP0067".
>
>
> Variables
> ---------
>
> * A "CMAKE_CODELITE_USE_TARGETS" variable was added to tell the
>    "CodeLite" extra generator to change the generated project to have
>    target-centric organization. The "build", "rebuild", and "clean"
>    operations within "CodeLite" then work on a selected target rather
>    than the whole workspace. (Note that the "Ninja" clean operation on
>    a target includes its dependencies, though.)
>
> * The "CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS" variable was added to tell
>    the "Sublime Text 2" extra generator to place specified environment
>    variables in the generated ".sublime-project".
>
> * The "CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE" variable was added
>    to tell the "Sublime Text 2" extra generator whether to exclude the
>    build tree from the ".sublime-project" when it is inside the source
>    tree.
>
> * A "CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD" variable was added
>    to tell Visual Studio Generators for VS 2010 and above to include
>    the "PACKAGE" target in the default build, similar to the existing
>    "CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" variable for the
>    "INSTALL" target.
>
>
> Properties
> ----------
>
> * A "BUILD_RPATH" target property and corresponding
>    "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH"
>    locations to be added to binaries in the build tree.
>
> * The "COMPILE_FLAGS" source file property learned to support
>    "generator expressions".
>
> * The "FRAMEWORK" target property may now also be applied to static
>    libraries on Apple targets.  It will result in a proper Framework
>    but with a static library inside.
>
> * Imported Interface Libraries learned new "IMPORTED_LIBNAME" and
>    "IMPORTED_LIBNAME_<CONFIG>" target properties to specify a link
>    library name since interface libraries do not build their own
>    library files.
>
> * A "<LANG>_CPPLINT" target property and supporting
>    "CMAKE_<LANG>_CPPLINT" variable were introduced to tell the Makefile
>    Generators and the "Ninja" generator to run the "cpplint" style
>    checker along with the compiler for "C" and "CXX" languages.
>
> * A "MANUALLY_ADDED_DEPENDENCIES" target property has been added. It
>    provides a read-only list of dependencies that have been added with
>    the "add_dependencies()" command.
>
> * The "MAP_IMPORTED_CONFIG_<CONFIG>" target property learned to
>    interpret empty list elements as referring to the configuration-less
>    imported location specified by "IMPORTED_LOCATION".
>
> * The "NO_SYSTEM_FROM_IMPORTED" target property is now supported on
>    Imported Interface Libraries.
>
> * New source file properties "SKIP_AUTOMOC", "SKIP_AUTOUIC",
>    "SKIP_AUTORCC", and "SKIP_AUTOGEN" were added to allow source files
>    to be excluded from processing by "AUTOMOC", "AUTOUIC", and
>    "AUTORCC" target properties.
>
> * A "VS_COPY_TO_OUT_DIR" source file property was added to tell
>    Visual Studio Generators for VS 2010 and above whether or not a file
>    should e copied to the output directory.
>
> * A "VS_DEBUGGER_WORKING_DIRECTORY" target property was added to
>    tell Visual Studio Generators for VS 2010 and above what debugger
>    working directory should be set for the target.
>
> * A "VS_DOTNET_REFERENCES_COPY_LOCAL" target property was added to
>    specify whether to copy referenced assemblies to the output
>    directory.
>
> * A "VS_DOTNET_REFERENCE_<refname>" target property was added to
>    tell Visual Studio Generators for VS 2010 and above to add a .NET
>    reference with a given hint path.
>
> * A "VS_INCLUDE_IN_VSIX" source file property was added to tell
>    Visual Studio Generators for VS 2010 and above whether to include
>    the file in a Visual Studio extension package.
>
> * A "VS_RESOURCE_GENERATOR" source file property was added to give
>    Visual Studio Generators for VS 2010 and above a setting for the
>    resource generator ("C#" only).
>
> * A "VS_USER_PROPS" target property was added to tell Visual Studio
>    Generators for VS 2010 and above to use a custom MSBuild user
>    ".props" file.
>
> * A "XCODE_EMIT_EFFECTIVE_PLATFORM_NAME" global property was added
>    to tell the "Xcode" generator whether to emit the
>    "EFFECTIVE_PLATFORM_NAME" variable.  This is useful when building
>    with multiple SDKs like "macosx" and "iphoneos" in parallel.
>
> * New "XCODE_PRODUCT_TYPE" and "XCODE_EXPLICIT_FILE_TYPE" target
>    properties were created to tell the "Xcode" generator to use custom
>    values of the corresponding attributes for a target in the generated
>    Xcode project.
>
>
> Modules
> -------
>
> * The "ExternalData" module learned to support multiple content
>    links for one data file using different hashes, e.g.
>    "img.png.sha256" and "img.png.sha1".  This allows objects to be
>    fetched from sources indexed by different hash algorithms.
>
> * The "ExternalProject" module gained the "GIT_PROGRESS" option to
>    force Git to show progress when cloning repositories.
>
> * The "ExternalProject" module gained a "GIT_CONFIG" option to pass
>    " --config" options to Git when cloning repositories.
>
> * The "FeatureSummary" module "feature_summary()" command now
>    accepts a new "QUIET_ON_EMPTY" option that suppresses the output
>    when the list of packages that belong to the selected category is
>    empty.
>
> * The "FeatureSummary" module "add_feature_info()" command now
>    accepts lists of dependencies for deciding whether a feature is
>    enabled or not.
>
> * The package types accepted by the "FeatureSummary" module can now
>    be tweaked by changing the "FeatureSummary_PKG_TYPES",
>    "FeatureSummary_REQUIRED_PKG_TYPES" and
>    "FeatureSummary_DEFAULT_PKG_TYPE" global properties.
>
> * The "FindOpenGL" module now provides imported targets "OpenGL::GL"
>    and "OpenGL::GLU" when the libraries are found.
>
> * The "UseSWIG" module gained a "swig_add_library" command to give
>    more flexibility over the old "swig_add_module" command.
>
> * The "UseSWIG" module "swig_add_source_to_module" command learned a
>    new "SWIG_OUTFILE_DIR" option to control the output file location
>    ("swig -o").
>
> * The "WriteCompilerDetectionHeader" module gained the
>    "ALLOW_UNKNOWN_COMPILERS" and "ALLOW_UNKNOWN_COMPILER_VERSIONS"
>    options that allow creation of headers that will work also with
>    unknown or old compilers by simply assuming they do not support any
>    of the requested features.
>
>
> CTest
> -----
>
> * The "ctest_memcheck()" command gained a "DEFECT_COUNT<var>"
>    option to capture the number of memory defects detected.
>
> * The "ctest_memcheck()" command learned to read the location of
>    suppressions files for sanitizers from the
>    "CTEST_MEMORYCHECK_SUPPRESSIONS_FILE" variable.
>
> * The "ctest_memcheck()" command learned to support "LeakSanitizer"
>    independently from "AddressSanitizer".
>
> * The "ctest_update()" command "CDASH_UPLOAD" signature was taught
>    to honor the "RETRY_COUNT", "RETRY_DELAY", and "QUIET" options.
>
>
> CPack
> -----
>
> * The "CPackIFWConfigureFile" module was added to define a new
>    "cpack_ifw_configure_file()" command to configure file templates
>    prepared in QtIFW/SDK/Creator style.
>
> * The "CPackIFW" module "cpack_ifw_configure_component()" and
>    "cpack_ifw_configure_component_group()" commands gained a new
>    "DEFAULT", "VIRTUAL", "FORCED_INSTALLATION",
>    "REQUIRES_ADMIN_RIGHTS", "DISPLAY_NAME", "UPDATE_TEXT",
>    "DESCRIPTION", "RELEASE_DATE", "AUTO_DEPEND_ON" and "TRANSLATIONS"
>    options to more specific configuration.
>
> * The "CPackIFW" module "cpack_ifw_configure_component()" command
>    gained a new "DEPENDENCIES" alias for "DEPENDS" option.
>
> * The "CPackIFW" module "cpack_ifw_configure_component_group()"
>    command gained a new "DEPENDS" option. The "DEPENDENCIES" alias also
>    added.
>
> * The "CPackIFW" module "cpack_ifw_configure_component()" and
>    "cpack_ifw_configure_component_group()" commands "PRIORITY" option
>    now is deprecated and will be removed in a future version of CMake.
>    Please use new "SORTING_PRIORITY" option instead.
>
> * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_WATERMARK",
>    "CPACK_IFW_PACKAGE_BANNER", "CPACK_IFW_PACKAGE_BACKGROUND",
>    "CPACK_IFW_PACKAGE_WIZARD_STYLE",
>    "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH",
>    "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT", and
>    "CPACK_IFW_PACKAGE_TITLE_COLOR" variables to customize a QtIFW
>    installer look.
>
> * The "CPackProductBuild" module gained options to sign packages.
>    See the variables "CPACK_PRODUCTBUILD_IDENTITY_NAME",
>    "CPACK_PRODUCTBUILD_KEYCHAIN_PATH", "CPACK_PKGBUILD_IDENTITY_NAME",
>    and "CPACK_PKGBUILD_KEYCHAIN_PATH".
>
> * The "CPackRPM" module learned to omit tags that are not supported
>    by provided "rpmbuild" tool. If unsupported tags are set they are
>    ignored and a developer warning is printed out.
>
> * The "CPackRPM" module learned to generate main component package
>    which forces generation of a rpm for defined component without
>    component suffix in filename and package name. See
>    "CPACK_RPM_MAIN_COMPONENT" variable.
>
> * The "CPackRPM" module learned to generate a single "debuginfo"
>    package on demand even if components packaging is used. See
>    "CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE" variable.
>
> * The "CPackRPM" module learned to support multiple directives per
>    file when using "CPACK_RPM_USER_FILELIST" variable.
>
>
> Other
> -----
>
> * CMake functionality using cryptographic hashes now supports SHA-3
>    algorithms.
>
> * A new generator expression "$<IF:cond,true-value,false-value>" was
>    added. It resolves to the true-value if the condition is "1" and
>    resolves to the false-value if the condition is "0".
>
>
> Deprecated and Removed Features
> ===============================
>
> * The "FeatureSummary" module commands "set_package_info()",
>    "set_feature_info()", "print_enabled_features()", and
>    "print_disabled_features()" are now deprecated.
>
> * The "UseSWIG" module "swig_add_module" command is now deprecated
>    in favor of "swig_add_library".
>
>
> Other Changes
> =============
>
> * If a command specified by the "<LANG>_CLANG_TIDY" target property
>    returns non-zero at build time this is now treated as an error
>    instead of silently ignored.
>
> * The "ctest_memcheck()" command no longer automatically adds
>    "leak_check=1" to the options used by "AddressSanitizer". The
>    default behavior of "AddressSanitizer" is to run *LeakSanitizer* to
>    check leaks unless "leak_check=0".
>
> * The "ctest_memcheck()" command was fixed to correctly append extra
>    sanitizer options read from the
>    "CTEST_MEMORYCHECK_SANITIZER_OPTIONS" variable to the environment
>    variables used internally by the sanitizers.
>
> * The "FeatureSummary" module "set_package_properties()" command no
>    longer forces the package type to "OPTIONAL" when the type is not
>    explicitly set.
>
> * The "Compile Features" functionality is now aware of features
>    supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX
>    and Windows platforms.
>
> * Calls to the "FindPkgConfig" module "pkg_check_modules()" command
>    following a successful call learned to re-evaluate the cached values
>    for a given prefix after changes to the parameters to the command
>    for that prefix.
>
> * When using "AUTOMOC" or "AUTOUIC", generated "moc_*", "*.moc" and
>    "ui_*" are placed in the
>    "<CMAKE_CURRENT_BINARY_DIR>/<TARGETNAME>_autogen/include" directory
>    which is automatically added to the target's "INCLUDE_DIRECTORIES".
>    It is therefore not necessary anymore to have
>    "CMAKE_CURRENT_BINARY_DIR" in the target's "INCLUDE_DIRECTORIES".
>
> * The "Sublime Text 2" generator no longer runs the native build
>    command (e.g. "ninja" or "make") with verbose build output enabled.
>
> * The "try_compile()" command source file signature now honors the
>    "CMAKE_WARN_DEPRECATED" variable value in the generated test
>    project.
>
> * The Visual Studio Generators for VS 2010 and above now place per-
>    source file flags after target-wide flags when they are classified
>    as raw flags with no project file setting ("AdditionalOptions").
>    This behavior is more consistent with the ordering of flags produced
>    by other generators, and allows flags on more-specific properties
>    (per-source) to override those on more general ones (per-target).
>
> * The precompiled Windows binary MSI package provided on "cmake.org"
>    now records the installation directory in the Windows Registry under
>    the key "HKLM\Software\Kitware\CMake" with a value named
>    "InstallDir".
--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cmake server-mode project order (was: CMake 3.8.0-rc1 now ready for testing!)

Brad King
On 02/07/2017 02:23 PM, Michael Jackson wrote:
> Are there any improvements to the cmake -server mode? I am testing the
> combination of QtCreator and CMake and there seemed to be an issue where
> the list of projects are in Alphabetical order and not in a "top down"
> order.

Tobias?

-Brad

--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cmake server-mode project order

Michael Jackson

Tobias Hunger wrote:

>
>
> On Feb 7, 2017 20:43, "Brad King" <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 02/07/2017 02:23 PM, Michael Jackson wrote:
>      > Are there any improvements to the cmake -server mode? I am
>     testing the
>      > combination of QtCreator and CMake and there seemed to be an
>     issue where
>      > the list of projects are in Alphabetical order and not in a "top
>     down"
>      > order.
>
>     Tobias?
>
>
> I admit that I did not yet notice that yet:-) I turn the whole thing
> into a tree anyway and do not care about the order of the elements.
>
> Server-mode is not doing anything special, it just grabs the project
> list from cmGlobalGenerator::GetProjectMap() and dumps it. That is a
> map, so now that I think about it, it is sorted by name:-)
>
> Yes, I could re-sort that to be in another order.
>
> Best Regards,
> Tobisa

This comes off mainly as a visual issue but also a but of a usability
issue. Our project is called "DREAM3D" but has a subproject called
"AMProcessMonitoring". After loading the project in QtCreator 4.3 beta
using CMake 3.7.1 (on OS X if that matters at all), the top level is
listed as "AMProcessMonitoring". Everything generally compiles fine from
there. If I close the project and go to QtCreators Welcome page I don't
see "DREAM3D" anymore but I see "AMProcessMonitoring" instead. Clicking
on the "AMProcessingMonitoring" link correctly opens the project. It is
just odd to see it that way.

So if you could somehow mark the top level project when you get the list
from CMake and percolate that to the QtCreator UI it would be really
great. So far the combination of QtCreator 4.3 and CMake 3.7.1 has
really great potential. There are still some rough spots but I generally
am really happy with this combination now.
--
Michael A. Jackson                 400 S. Pioneer Blvd
Owner, President                   Springboro, Ohio 45066
BlueQuartz Software, LLC           EMail: [hidden email]
Voice: 937-790-1601                Web: http://www.bluequartz.net
Fax: 937-746-0783
--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cmake server-mode project order

Brad King
On 02/08/2017 01:26 AM, Tobias Hunger wrote:
> There still are some rough spots in creators support for server-mode.
> Currently I am trying to get all the basic features in and leave
> polishing and fixing the non-critical bugs for later.

Has it become mature enough that the cmake server protocol should
be made non-experimental for CMake 3.9?

-Brad

--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: cmake server-mode project order

Brad King
On 02/08/2017 09:13 AM, Tobias Hunger wrote:
> I know a couple of people are looking into using server-mode, so let's
> give them a bit more time and decide shortly before feature freeze for
> CMake 3.9. Does that sound like a reasonable plan?

Sure.  I'll defer to you to decide when it's ready.

Thanks,
-Brad

--

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
Loading...