[cmake-developers] [ANNOUNCE] CMake 3.8.0-rc2 now ready for testing!

2017-03-03 Thread Robert Maynard
I am proud to announce the second 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 "$" 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_" 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, ...).


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.


Platfo

Re: [cmake-developers] [ANNOUNCE] CMake merge process transition

2017-03-03 Thread Brad King
On 03/02/2017 03:55 PM, Brad King wrote:
> Once we have actually made the final transition I'll merge the new
> instructions and post a link here to their final URL.

The transition is complete!  Documentation of the review process is
now rendered directly on the gitlab repo page [1].  The canonical
entry point for contributors is still the CONTRIBUTING.rst file [2].
There is also a new place to index developer documentation [3].

[1] https://gitlab.kitware.com/cmake/cmake/blob/master/Help/dev/review.rst
[2] https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst
[3] https://gitlab.kitware.com/cmake/cmake/blob/master/Help/dev/README.rst


CONTRIBUTING.rst now suggests running `Utilities/SetupForDevelopment.sh`.
This script has been updated [4] to drop the old configuration of ssh
access to cmake.org repositories.  It is now suitable for all contributors
to run.

[4] https://gitlab.kitware.com/cmake/cmake/merge_requests/546

> Furthermore, the staging branch will not be published as an official
> branch under refs/heads/ on the gitlab.kitware.com/cmake/cmake repo.
> Instead it will be in a custom refs/ path that Git does not clone or
> fetch by default.  CTest scripts used to drive nightly testing will
> need to be adapted for this.  I'll post more information for those of
> you running nightly builds once we are ready to update the clients.

For now the nightly builds will continue to work as before, fetching
from the cmake.org repository.  The `master`, `nightly-master`, `next`,
and `nightly` branches there are now all maintained by a robot that
mirrors the equivalent new refs in the gitlab repository.  I have some
CTest script updates to move clients to following the gitlab repository
directly and will work on deploying them soon.

-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-developers