From Anil.Yadav at riotinto.com  Fri Jun  2 05:56:46 2017
From: Anil.Yadav at riotinto.com (Yadav, Anil (TI-IGATETECHNOLOGIESINC))
Date: Fri, 2 Jun 2017 09:56:46 +0000
Subject: [cmake-developers] Desktop shortcut icon in msi installer using
	CPack
Message-ID: <FFA5A1E672B7E04891D59E56EA0C620D02E9EC25@AUPEREXC6N2.corp.riotinto.org>

Hi,

I am new to CPack and WiX. I try to create desktop shortcut icons using cpack.
To achieve this I am using CPACK_CREATE_DESKTOP_LINKS . its create shortcuts without icon.
Is there any way to add icons?

Thanks in advance for helping me.

Regards,
Anil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170602/bee15431/attachment.html>

From comicfans44 at gmail.com  Mon Jun  5 10:33:40 2017
From: comicfans44 at gmail.com (comic fans)
Date: Mon, 5 Jun 2017 10:33:40 -0400
Subject: [cmake-developers] how can I set per-config rpath ?
Message-ID: <CAKzW8o=hTs0p99MT8w1YAVe8E74kfz51MuBF+mPPtPk98Kpa6A@mail.gmail.com>

cmake/tests/jump/executable script called link_directories to set rpath,
how could I set this per-config ?(debug exe use debug library output
dir as rpath,
release exe use release library output dir as rpath) .   this is for
experimental
fastbuild generator test, which supports running in linux and multi-config

From brad.king at kitware.com  Mon Jun  5 13:11:24 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 5 Jun 2017 13:11:24 -0400
Subject: [cmake-developers] CMake 3.9 feature freeze on 2017-06-01
In-Reply-To: <ecd58ffe-7c69-e2a4-03b5-850dc8330dbc@kitware.com>
References: <c369ad7a-0d23-69e1-d2f2-0e53a1fed9d4@kitware.com>
 <ecd58ffe-7c69-e2a4-03b5-850dc8330dbc@kitware.com>
Message-ID: <409b702c-06f9-1950-b9ed-43d6b15c2ec6@kitware.com>

On 05/30/2017 11:31 AM, Brad King wrote:
> I'll announce when post-3.9 development is open.

I've branched 'release' for 3.9.  The repository is now open for
post-3.9 development.  Please rebase open merge requests on 'master'
before staging or merging.

> Meanwhile the following types of changes are still welcome:
>
> * Documentation updates
> * Regression fixes
> * Fixes for bugs in features new to 3.9

These types of changes may still be accepted to 'release' during
the 3.9 release candidate cycle.  The 3.9 release is now closed
to new features and general bug fixes.

-Brad


From robert.maynard at kitware.com  Mon Jun  5 14:59:47 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 5 Jun 2017 14:59:47 -0400
Subject: [cmake-developers] [ANNOUNCE] CMake 3.9.0-rc1 now ready for testing
Message-ID: <CAFzjYVo2eJDxTC9LBZ-kVaZh7uTm3RcD8ARrCoxPv0YrGBg_Pg@mail.gmail.com>

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

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

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

Some of the more significant changes in CMake 3.9 are:

* "CUDA" is now supported by the Visual Studio Generators for VS
  2010 and above.  This complements the existing support by the
  Makefile Generators and the "Ninja" generator.

* The "add_library()" command "IMPORTED" option learned to support
  Object Libraries.

* All "find_" commands now have a "PACKAGE_ROOT" search path group
  that is first in the search heuristics.  If a "find_" command is
  called from inside a find module, then the CMake variable and
  environment variable named "<PackageName>_ROOT" are used as prefixes
  and are the first set of paths to be searched.

* The "install(TARGETS)" command learned a new "OBJECTS" option to
  specify where to install Object Libraries.

* The "install(EXPORT)" command learned how to export Object
  Libraries.

* A "BUILD_WITH_INSTALL_NAME_DIR" target property and corresponding
  "CMAKE_BUILD_WITH_INSTALL_NAME_DIR" variable were added to control
  whether to use the "INSTALL_NAME_DIR" target property value for
  binaries in the build tree.  This is for macOS "install_name" as
  "BUILD_WITH_INSTALL_RPATH" is for "RPATH".

* A "CUDA_PTX_COMPILATION" target property was added to Object
  Libraries to support compiling to ".ptx" files instead of host
  object files.

* A new "GoogleTest" module was added to provide the
  "gtest_add_tests()" function independently of the "FindGTest"
  module. The function was also updated to support keyword arguments,
  with functionality expanded to allow a test name prefix and suffix
  to be specified, the dependency on the source files to be optional
  and the list of discovered test cases to be returned to the caller.

* The "Ninja" generator has loosened the dependencies of object
  compilation.  Object compilation now depends only on custom targets
  and custom commands associated with libraries on which the object's
  target depends and no longer depends on the libraries themselves.
  Source files in dependent targets may now compile without waiting
  for their targets' dependencies to link.

* Interprocedural optimization (IPO) is now supported for GNU and
  Clang compilers using link time optimization (LTO) flags.  See the
  "INTERPROCEDURAL_OPTIMIZATION" target property and
  "CheckIPOSupported" module.

* The "TARGET_OBJECTS" "generator expression" is now supported by
  the "add_custom_command()" and "file(GENERATE)" commands.

CMake 3.9 Release Notes
***********************

Changes made since CMake 3.8 include the following.


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


Languages
---------

* "CUDA" is now supported by the Visual Studio Generators for VS
  2010 and above.  This complements the existing support by the
  Makefile Generators and the "Ninja" generator.


Generators
----------

* Visual Studio Generators for VS 2010 and above learned to support
  the "ASM_NASM" language when "nasm" is installed.

* The "Xcode" generator learned to create Xcode schema files. This
  is an experimental feature and can be activated by setting the
  "CMAKE_XCODE_GENERATE_SCHEME" variable to a "TRUE" value.


Commands
--------

* The "add_library()" command "IMPORTED" option learned to support
  Object Libraries.

* All "find_" commands now have a "PACKAGE_ROOT" search path group
  that is first in the search heuristics.  If a "find_" command is
  called from inside a find module, then the CMake variable and
  environment variable named "<PackageName>_ROOT" are used as prefixes
  and are the first set of paths to be searched.

* The "find_library()" command learned to search "libx32" paths when
  the build targets the "x32" ABI.  See the
  "FIND_LIBRARY_USE_LIBX32_PATHS" global property.

* The "include_external_msproject()" command learned to use the
  "MAP_IMPORTED_CONFIG_<CONFIG>" target property to map current
  configurations to the external configurations.

* The "install(TARGETS)" command learned a new "OBJECTS" option to
  specify where to install Object Libraries.

* The "install(EXPORT)" command learned how to export Object
  Libraries.

* The "project()" command learned an optional "DESCRIPTION"
  parameter to set the "PROJECT_DESCRIPTION" variable.

* The "separate_arguments()" command gained a "NATIVE_COMMAND" mode
  that performs argument separation depending on the host operating
  system.


Variables
---------

* A "CMAKE_AUTOMOC_DEPEND_FILTERS" variable was introduced to allow
  "CMAKE_AUTOMOC" to extract additional dependency file names for
  "moc" from the contents of source files.

* A "CMAKE_AUTOUIC_SEARCH_PATHS" variable was introduced to allow
  "CMAKE_AUTOUIC" to search for "foo.ui" in more places than the
  vicinity of the file including "ui_foo.h".

* A "CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX" variable was added to
  tell the "find_library()" command to search in a "lib<suffix>"
  directory before each "lib" directory that would normally be
  searched.

* A "CMAKE_INTERPROCEDURAL_OPTIMIZATION" variable was added to
  initialize the "INTERPROCEDURAL_OPTIMIZATION" property on all
  targets.

* A "CMAKE_<LANG>_COMPILER_AR" variable was added to hold the path
  to the GCC/Clang wrapper of "ar".

* A "CMAKE_<LANG>_COMPILER_RANLIB" variable was added to hold the
  path to the GCC/Clang wrapper of "ranlib".

* The "CMAKE_SYSROOT_COMPILE" and "CMAKE_SYSROOT_LINK" variables
  were added to use separate sysroots for compiling and linking.


Properties
----------

* A new "AUTOGEN_BUILD_DIR" target property was introduced to set a
  custom output directory for "AUTOMOC", "AUTOUIC", and "AUTORCC".

* A new "AUTOMOC_DEPEND_FILTERS" target property was introduced to
  allow "AUTOMOC" to extract additional dependency file names for
  "moc" from the contents of source files.

* A new "AUTOUIC_SEARCH_PATHS" target property was introduced to
  allow "AUTOUIC" to search for "foo.ui" in more places than the
  vicinity of the file including "ui_foo.h".

* Global properties "AUTOGEN_SOURCE_GROUP", "AUTOMOC_SOURCE_GROUP"
  and "AUTORCC_SOURCE_GROUP" were introduced to allow files generated
  by "AUTOMOC" or "AUTORCC" to be placed in a "source_group()".

* A "BUILD_WITH_INSTALL_NAME_DIR" target property and corresponding
  "CMAKE_BUILD_WITH_INSTALL_NAME_DIR" variable were added to control
  whether to use the "INSTALL_NAME_DIR" target property value for
  binaries in the build tree.  This is for macOS "install_name" as
  "BUILD_WITH_INSTALL_RPATH" is for "RPATH".

* A "CUDA_PTX_COMPILATION" target property was added to Object
  Libraries to support compiling to ".ptx" files instead of host
  object files.

* A "GENERATOR_IS_MULTI_CONFIG" global property was added to
  determine whether the current generator is a multi-configuration
  generator (such as Visual Studio Generators or "Xcode").

* The "INTERPROCEDURAL_OPTIMIZATION" target property is now enforced
  when enabled.  CMake will add IPO flags unconditionally or produce
  an error if it does not know the flags for the current compiler. The
  project is now responsible to use the "CheckIPOSupported" module to
  check for IPO support before enabling the target property.  See
  policy "CMP0069".

* The "WINDOWS_EXPORT_ALL_SYMBOLS" target property may now be used
  in combination with explicit ".def" files in order to export all
  symbols from the object files within a target plus an explicit list
  of symbols that the linker finds in dependencies (e.g.
  "msvcrt.lib").


Modules
-------

* A "CheckIPOSupported" module was added to help projects check
  whether interprocedural optimization (IPO) is supported by the
  current toolchain and CMake version.

* The "FeatureSummary" module "feature_summary()" command now
  accepts the new "DEFAULT_DESCRIPTION" option that will print the
  default title for the selected package type.

* The "FeatureSummary" module gained a new
  "FeatureSummary_<TYPE>_DESCRIPTION" variable that can be defined for
  each "<TYPE>" to replace the type name with the specified string
  whenever the package type is used in an output string by the module.

* The "FindDoxygen" module learned to control Doxygen behavior using
  CMake variables and generate documentation via the newly added
  "doxygen_add_docs()" function. The Doxygen input file ("Doxyfile")
  is automatically generated and doxygen is run as part of a custom
  target. Additional components can be specified to find optional
  tools: "dot", "mscgen" and "dia".

* The "FindMPI" module now provides imported targets.

* The "FindProtobuf" module "protobuf_generate_cpp()" command gained
  an "EXPORT_MACRO" option to specify the name of a DLL export markup
  macro.

* The "FindProtobuf" module now supports usage of static libraries
  for Unix via a new "Protobuf_USE_STATIC_LIBS" input variable.

* The "FindProtobuf" module now provides imported targets when the
  libraries are found.

* A new "GoogleTest" module was added to provide the
  "gtest_add_tests()" function independently of the "FindGTest"
  module. The function was also updated to support keyword arguments,
  with functionality expanded to allow a test name prefix and suffix
  to be specified, the dependency on the source files to be optional
  and the list of discovered test cases to be returned to the caller.


CTest
-----

* The "ctest_submit()" command gained a "HTTPHEADER" option to
  specify custom headers to send during submission.

* The "ctest(1)" executable gained new options which allow the
  developer to disable automatically adding tests to the test set to
  satisfy fixture dependencies. "-FS" prevents adding setup tests for
  fixtures matching the provided regular expression, "-FC" prevents
  adding cleanup tests for matching fixtures and "-FA" prevents adding
  any test for matching fixtures.

* A "DISABLED" test property was added to mark tests that are
  configured but explicitly disabled so they do not run.


CPack
-----

* The "CPackArchive" module learned to modify the filename per-
  component.  See the "CPACK_ARCHIVE_FILE_NAME" variable and its per-
  component version "CPACK_ARCHIVE_<component>_FILE_NAME".

* The "CPackComponent" module "cpack_add_component()" command gained
  a new "PLIST <filename>" option to specify the "pkgbuild" "--
  component-plist" argument when using the "productbuild" generator.

* The "CPackIFW" module "cpack_ifw_configure_component()" and
  "cpack_ifw_configure_component_group()" commands gained
  internationalization support for "DISPLAY_NAME" and "DESCRIPTION"
  options.

* The "CPackIFW" module learned the new hint "CPACK_IFW_ROOT"
  variable for finding the QtIFW tool suite installed in a non-
  standard place.

* The "CPackProductBuild" module gained a new
  "CPACK_PRODUCTBUILD_RESOURCES_DIR" variable to specify resources to
  be copied into the "Resources" directory.

* The "CPackRPM" module learned to modify the "debuginfo" package
  name.  See the "CPACK_RPM_DEBUGINFO_FILE_NAME" variable.

* The "CPackWIX" module patching system now has the ability to set
  additional attributes.  This can be done by specifying attributes
  with the "CPackWiXFragment" XML tag after the "Id" attribute. See
  the "CPACK_WIX_PATCH_FILE" variable.

* The CPack WIX generator implemented a new
  "CPACK_WIX_ROOT_FOLDER_ID" variable which allows using a custom root
  folder ID instead of the default "ProgramFilesFolder" /
  "ProgramFiles64Folder".


Other
-----

* Interprocedural optimization (IPO) is now supported for GNU and
  Clang compilers using link time optimization (LTO) flags.  See the
  "INTERPROCEDURAL_OPTIMIZATION" target property and
  "CheckIPOSupported" module.

* The "TARGET_OBJECTS" "generator expression" is now supported by
  the "add_custom_command()" and "file(GENERATE)" commands.

* Two new informational generator expressions to retrieve Apple
  Bundle directories have been added. The first one
  "$<TARGET_BUNDLE_DIR:tgt>" outputs the full path to the Bundle
  directory, the other one "$<TARGET_BUNDLE_CONTENT_DIR:tgt>" outputs
  the full path to the "Contents" directory of macOS Bundles and App
  Bundles. For all other bundle types and SDKs it is identical with
  "$<TARGET_BUNDLE_DIR:tgt>". The new expressions are helpful to query
  Bundle locations independent of the different Bundle types and
  layouts on macOS and iOS.


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

* An explicit deprecation diagnostic was added for policies
  "CMP0036" and below.  The "cmake-policies(7)" manual explains that
  the OLD behaviors of all policies are deprecated and that projects
  should always port to the NEW behaviors as soon as possible.

* The "Visual Studio 8 2005" generator is now deprecated and will be
  removed in a future version of CMake.

* The "Visual Studio 7 .NET 2003" generator has been removed.

* The "Xcode" generator dropped support for Xcode versions older
  than 3.

* The "FindDoxygen" module has deprecated several variables.

* The version of curl bundled with CMake no longer accepts URLs of
  the form "file://c:/..." on Windows due to a change in upstream curl
  7.52.  Use the form "file:///c:/..." instead to work on all
  versions.


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

* When using "AUTOMOC", CMake now scans for the presence of the
  "Q_PLUGIN_METADATA" macro and reruns moc when the file from the
  macro's "FILE" argument changes.

* When "AUTOMOC" detects an include statement of the form "#include
  "moc_<basename>.cpp"" the search for the respective header file now
  looks in the "INCLUDE_DIRECTORIES" of the target as well.

* When running tests, CTest learned to treat skipped tests (using
  the "SKIP_RETURN_CODE" property) the same as tests with the new
  "DISABLED" property. Due to this change, CTest will not indicate
  failure when all tests are either skipped or pass.

* The "Ninja" generator has loosened the dependencies of object
  compilation.  Object compilation now depends only on custom targets
  and custom commands associated with libraries on which the object's
  target depends and no longer depends on the libraries themselves.
  Source files in dependent targets may now compile without waiting
  for their targets' dependencies to link.

* On macOS, the default application bundle "Info.plist" file now
  enables Hi-DPI support.

* On macOS, "RPATH" settings such as "BUILD_WITH_INSTALL_RPATH" no
  longer affect the "install_name" field.  See policy "CMP0068".

From DLRdave at aol.com  Mon Jun  5 16:10:21 2017
From: DLRdave at aol.com (David Cole)
Date: Mon, 5 Jun 2017 16:10:21 -0400
Subject: [cmake-developers] Question about ALIAS targets
Message-ID: <CAKME8fFHCexKXb0xpxbaodM13YSeE5j3xZfShbrawzWoigF9hQ@mail.gmail.com>

Is there a good reason why this error must be an error?

    CMake Error at CMakeLists.txt:23 (add_library):
      add_library cannot create ALIAS target "MyProj::gtest" because target
      "OtherProj::googletest" is IMPORTED.

The line of code is:

    add_library(MyProj::gtest ALIAS OtherProj::googletest)

Why is there any restriction on ALIAS targets about what sorts of
targets they may be aliases of?

After my find_package(OtherProj) call, which is a super build which
defines lots of imported targets, I want the target to be named gtest
to match its library name, but OtherProj has named it googletest.

I can brute force this particular one to just be another IMPORTED
target with all the same properties and property values as the
original, but it seems to me this particular case should be allowed
unless there's a fundamental problem I'm not aware of.

Thanks for any explanations....


David C.

From brad.king at kitware.com  Mon Jun  5 16:35:50 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 5 Jun 2017 16:35:50 -0400
Subject: [cmake-developers] how can I set per-config rpath ?
In-Reply-To: <CAKzW8o=hTs0p99MT8w1YAVe8E74kfz51MuBF+mPPtPk98Kpa6A@mail.gmail.com>
References: <CAKzW8o=hTs0p99MT8w1YAVe8E74kfz51MuBF+mPPtPk98Kpa6A@mail.gmail.com>
Message-ID: <e40c86fe-c63f-afec-7d32-0e3dc2a8ea3e@kitware.com>

On 06/05/2017 10:33 AM, comic fans wrote:
> cmake/tests/jump/executable script called link_directories to set rpath,
> how could I set this per-config ?(debug exe use debug library output
> dir as rpath, release exe use release library output dir as rpath).
> this is for experimental fastbuild generator test, which supports running
> in linux and multi-config

I don't think we have a model for per-config rpath currently.  The only
multi-config generator we have on a platform that defines rpath is Xcode
on macOS.

Note that we have two different rpath values: one for the build tree
(e.g. from link_directories or the locations of linked libraries),
and one for the install tree (INSTALL_RPATH).  The places evaluating
each of these should already be per-config, but are only ever evaluated
for one configuration by the Makefile and Ninja generators.

The build tree rpath comes from locations of artifacts and other things
that are already per-config.  For INSTALL_RPATH perhaps generator expression
support would be needed.

-Brad


From brad.king at kitware.com  Mon Jun  5 16:38:21 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 5 Jun 2017 16:38:21 -0400
Subject: [cmake-developers] Question about ALIAS targets
In-Reply-To: <CAKME8fFHCexKXb0xpxbaodM13YSeE5j3xZfShbrawzWoigF9hQ@mail.gmail.com>
References: <CAKME8fFHCexKXb0xpxbaodM13YSeE5j3xZfShbrawzWoigF9hQ@mail.gmail.com>
Message-ID: <4a0dce85-afe1-248a-b349-649f3f4f1924@kitware.com>

On 06/05/2017 04:10 PM, David Cole via cmake-developers wrote:
> Why is there any restriction on ALIAS targets about what sorts of
> targets they may be aliases of?

Adding Steve (who added ALIAS targets) to Cc.

The use case in the documentation:

 https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html#alias-targets

is the only one that was really designed.  It is for making in-project
build targets available to other directories in the project under the
same name that an externally-built project might see it as an imported
target.  This allows tests and examples to use the name that client code
would.  Of course only in-project build targets need to be aliased for this.

Steve, is there any reason for the restriction other than not implementing
more use cases up front?

Thanks,
-Brad


From steveire at gmail.com  Mon Jun  5 17:39:14 2017
From: steveire at gmail.com (Stephen Kelly)
Date: Mon, 05 Jun 2017 22:39:14 +0100
Subject: [cmake-developers] Question about ALIAS targets
References: <CAKME8fFHCexKXb0xpxbaodM13YSeE5j3xZfShbrawzWoigF9hQ@mail.gmail.com>
Message-ID: <oh4j1t$rrj$1@blaine.gmane.org>

David Cole via cmake-developers wrote:

> Is there a good reason why this error must be an error?
> 
>     CMake Error at CMakeLists.txt:23 (add_library):
>       add_library cannot create ALIAS target "MyProj::gtest" because
>       target "OtherProj::googletest" is IMPORTED.
> 
> The line of code is:
> 
>     add_library(MyProj::gtest ALIAS OtherProj::googletest)
> 
> Why is there any restriction on ALIAS targets about what sorts of
> targets they may be aliases of?

They were introduced here:

 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=370bf554151a1

Aside from the information there, other commits may have extended or tweaked 
the features/restrictions.


> After my find_package(OtherProj) call, which is a super build which
> defines lots of imported targets, I want the target to be named gtest
> to match its library name, but OtherProj has named it googletest.

Why isn't there a standard name? Should upstream provide the imported 
target? Has any effort been made to make upstream provide it? Is the name 
from OtherProj namespaced? Why do you need it to have a particular name? Why 
does OtherProj expose it? Should it expose that target for you to use (it 
seems an internal thing to me)?

Thanks,

Steve.



From steveire at gmail.com  Mon Jun  5 17:45:26 2017
From: steveire at gmail.com (Stephen Kelly)
Date: Mon, 05 Jun 2017 22:45:26 +0100
Subject: [cmake-developers] Question about ALIAS targets
References: <CAKME8fFHCexKXb0xpxbaodM13YSeE5j3xZfShbrawzWoigF9hQ@mail.gmail.com>
 <4a0dce85-afe1-248a-b349-649f3f4f1924@kitware.com>
Message-ID: <oh4jdh$jr7$1@blaine.gmane.org>

Brad King wrote:

> Steve, is there any reason for the restriction other than not implementing
> more use cases up front?

There may be more information in the mailing list archives, but as far as I 
remember, yes - we wanted to be conservative because we didn't know more 
use-cases. Additionally, we didn't know the impact of making the feature 
more unrestricted. 

Eg - making it easy to alias imported targets means you can easily get 
imported target names which vary per project (Qt5::Core, Qt5::QtCore, 
TheQt5CoreLibrary etc) which doesn't seem useful. An desire to be able to do 
that may just be a mask on an underlying problem. CMake doesn't need 
multiple 'equally good' ways to solve the same problem.

Thanks,

Steve.



From brad.king at kitware.com  Tue Jun  6 08:22:25 2017
From: brad.king at kitware.com (Brad King)
Date: Tue, 6 Jun 2017 08:22:25 -0400
Subject: [cmake-developers] Question about ALIAS targets
In-Reply-To: <oh4jdh$jr7$1@blaine.gmane.org>
References: <CAKME8fFHCexKXb0xpxbaodM13YSeE5j3xZfShbrawzWoigF9hQ@mail.gmail.com>
 <4a0dce85-afe1-248a-b349-649f3f4f1924@kitware.com>
 <oh4jdh$jr7$1@blaine.gmane.org>
Message-ID: <47d97e91-911e-8144-ef7d-d56a3919a56f@kitware.com>

On 06/05/2017 05:45 PM, Stephen Kelly wrote:
> Eg - making it easy to alias imported targets means you can easily get 
> imported target names which vary per project (Qt5::Core, Qt5::QtCore, 
> TheQt5CoreLibrary etc) which doesn't seem useful.

If we were to allow aliases of imported targets we'd also have to work
out the scoping rules (global v. local).

-Brad


From DLRdave at aol.com  Tue Jun  6 11:06:24 2017
From: DLRdave at aol.com (David Cole)
Date: Tue, 6 Jun 2017 11:06:24 -0400
Subject: [cmake-developers] Question about ALIAS targets
In-Reply-To: <oh4j1t$rrj$1@blaine.gmane.org>
References: <CAKME8fFHCexKXb0xpxbaodM13YSeE5j3xZfShbrawzWoigF9hQ@mail.gmail.com>
 <oh4j1t$rrj$1@blaine.gmane.org>
Message-ID: <CAKME8fEJ=Cm-i1uznLzwcYn0Ki+MDoWfnqz0EoY_sHHtgsq6Ow@mail.gmail.com>

>> After my find_package(OtherProj) call, which is a super build which
>> defines lots of imported targets, I want the target to be named gtest
>> to match its library name, but OtherProj has named it googletest.
>
> Why isn't there a standard name? Should upstream provide the imported
> target? Has any effort been made to make upstream provide it? Is the name
> from OtherProj namespaced? Why do you need it to have a particular name? Why
> does OtherProj expose it? Should it expose that target for you to use (it
> seems an internal thing to me)?
>

There is a standard name. "Upstream" in this case is a super build of
many projects, with an imported target for each project named after
the project that means "the main lib (or all the libs) in the
project". Now, for projects that already have "good imported targets"
(Qt, VTK), I don't bother creating imported targets, I allow client
projects to link directly to those imported targets. But for projects
that don't, I create a convenience imported target named after the
project.

In the case of googletest, the project name is named for its GitHub
repo, but there is no library of that name and its install provides no
imported targets. And the "main" library is just gtest. So I create an
imported target named after the project, but in this case, I also want
to create an imported target for each lib. So I do, but that means my
googletest and gtest targets are essentially identical except for
their names. ( ** i.e. aliases of each other, but both imported... **
)

I don't need it to have a particular name, but I want to follow a
chain of naming conventions: naming the project after its repo,
keeping an imported target for each project in my super build named
after the project, and then, where it makes sense, also having
per-library imported targets.

I'm not expecting anybody to do any work on this, or to loosen the
restriction for my convenience... I just wanted to know if there were
a good reason for the error message. Sounds like "nobody needed it
yet, and we were being conservative" is the answer. Which is a good
answer.


Thanks,
David C.

From robert.maynard at kitware.com  Wed Jun  7 14:59:58 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 7 Jun 2017 14:59:58 -0400
Subject: [cmake-developers] [ANNOUNCE] CMake 3.9.0-rc2 is now ready for
	testing!
Message-ID: <CAFzjYVr+UhxnS9bGGn20HmpGWnLLKcACKzUBd3w=uEDqfcD17w@mail.gmail.com>

I am proud to announce the second CMake 3.9 release candidate.
  https://cmake.org/download/

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

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

Some of the more significant changes in CMake 3.9 are:

* "CUDA" is now supported by the Visual Studio Generators for VS
  2010 and above.  This complements the existing support by the
  Makefile Generators and the "Ninja" generator.

* The "add_library()" command "IMPORTED" option learned to support
  Object Libraries.

* All "find_" commands now have a "PACKAGE_ROOT" search path group
  that is first in the search heuristics.  If a "find_" command is
  called from inside a find module, then the CMake variable and
  environment variable named "<PackageName>_ROOT" are used as prefixes
  and are the first set of paths to be searched.

* The "install(TARGETS)" command learned a new "OBJECTS" option to
  specify where to install Object Libraries.

* The "install(EXPORT)" command learned how to export Object
  Libraries.

* A "BUILD_WITH_INSTALL_NAME_DIR" target property and corresponding
  "CMAKE_BUILD_WITH_INSTALL_NAME_DIR" variable were added to control
  whether to use the "INSTALL_NAME_DIR" target property value for
  binaries in the build tree.  This is for macOS "install_name" as
  "BUILD_WITH_INSTALL_RPATH" is for "RPATH".

* A "CUDA_PTX_COMPILATION" target property was added to Object
  Libraries to support compiling to ".ptx" files instead of host
  object files.

* A new "GoogleTest" module was added to provide the
  "gtest_add_tests()" function independently of the "FindGTest"
  module. The function was also updated to support keyword arguments,
  with functionality expanded to allow a test name prefix and suffix
  to be specified, the dependency on the source files to be optional
  and the list of discovered test cases to be returned to the caller.

* The "Ninja" generator has loosened the dependencies of object
  compilation.  Object compilation now depends only on custom targets
  and custom commands associated with libraries on which the object's
  target depends and no longer depends on the libraries themselves.
  Source files in dependent targets may now compile without waiting
  for their targets' dependencies to link.

* Interprocedural optimization (IPO) is now supported for GNU and
  Clang compilers using link time optimization (LTO) flags.  See the
  "INTERPROCEDURAL_OPTIMIZATION" target property and
  "CheckIPOSupported" module.

* The "TARGET_OBJECTS" "generator expression" is now supported by
  the "add_custom_command()" and "file(GENERATE)" commands.

CMake 3.9 Release Notes
***********************

Changes made since CMake 3.8 include the following.


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


Languages
---------

* "CUDA" is now supported by the Visual Studio Generators for VS
  2010 and above.  This complements the existing support by the
  Makefile Generators and the "Ninja" generator.


Generators
----------

* Visual Studio Generators for VS 2010 and above learned to support
  the "ASM_NASM" language when "nasm" is installed.

* The "Xcode" generator learned to create Xcode schema files. This
  is an experimental feature and can be activated by setting the
  "CMAKE_XCODE_GENERATE_SCHEME" variable to a "TRUE" value.


Commands
--------

* The "add_library()" command "IMPORTED" option learned to support
  Object Libraries.

* All "find_" commands now have a "PACKAGE_ROOT" search path group
  that is first in the search heuristics.  If a "find_" command is
  called from inside a find module, then the CMake variable and
  environment variable named "<PackageName>_ROOT" are used as prefixes
  and are the first set of paths to be searched.

* The "find_library()" command learned to search "libx32" paths when
  the build targets the "x32" ABI.  See the
  "FIND_LIBRARY_USE_LIBX32_PATHS" global property.

* The "include_external_msproject()" command learned to use the
  "MAP_IMPORTED_CONFIG_<CONFIG>" target property to map current
  configurations to the external configurations.

* The "install(TARGETS)" command learned a new "OBJECTS" option to
  specify where to install Object Libraries.

* The "install(EXPORT)" command learned how to export Object
  Libraries.

* The "project()" command learned an optional "DESCRIPTION"
  parameter to set the "PROJECT_DESCRIPTION" variable.

* The "separate_arguments()" command gained a "NATIVE_COMMAND" mode
  that performs argument separation depending on the host operating
  system.


Variables
---------

* A "CMAKE_AUTOMOC_DEPEND_FILTERS" variable was introduced to allow
  "CMAKE_AUTOMOC" to extract additional dependency file names for
  "moc" from the contents of source files.

* A "CMAKE_AUTOUIC_SEARCH_PATHS" variable was introduced to allow
  "CMAKE_AUTOUIC" to search for "foo.ui" in more places than the
  vicinity of the file including "ui_foo.h".

* A "CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX" variable was added to
  tell the "find_library()" command to search in a "lib<suffix>"
  directory before each "lib" directory that would normally be
  searched.

* A "CMAKE_INTERPROCEDURAL_OPTIMIZATION" variable was added to
  initialize the "INTERPROCEDURAL_OPTIMIZATION" property on all
  targets.

* A "CMAKE_<LANG>_COMPILER_AR" variable was added to hold the path
  to the GCC/Clang wrapper of "ar".

* A "CMAKE_<LANG>_COMPILER_RANLIB" variable was added to hold the
  path to the GCC/Clang wrapper of "ranlib".

* The "CMAKE_SYSROOT_COMPILE" and "CMAKE_SYSROOT_LINK" variables
  were added to use separate sysroots for compiling and linking.


Properties
----------

* A new "AUTOGEN_BUILD_DIR" target property was introduced to set a
  custom output directory for "AUTOMOC", "AUTOUIC", and "AUTORCC".

* A new "AUTOMOC_DEPEND_FILTERS" target property was introduced to
  allow "AUTOMOC" to extract additional dependency file names for
  "moc" from the contents of source files.

* A new "AUTOUIC_SEARCH_PATHS" target property was introduced to
  allow "AUTOUIC" to search for "foo.ui" in more places than the
  vicinity of the file including "ui_foo.h".

* Global properties "AUTOGEN_SOURCE_GROUP", "AUTOMOC_SOURCE_GROUP"
  and "AUTORCC_SOURCE_GROUP" were introduced to allow files generated
  by "AUTOMOC" or "AUTORCC" to be placed in a "source_group()".

* A "BUILD_WITH_INSTALL_NAME_DIR" target property and corresponding
  "CMAKE_BUILD_WITH_INSTALL_NAME_DIR" variable were added to control
  whether to use the "INSTALL_NAME_DIR" target property value for
  binaries in the build tree.  This is for macOS "install_name" as
  "BUILD_WITH_INSTALL_RPATH" is for "RPATH".

* A "CUDA_PTX_COMPILATION" target property was added to Object
  Libraries to support compiling to ".ptx" files instead of host
  object files.

* A "GENERATOR_IS_MULTI_CONFIG" global property was added to
  determine whether the current generator is a multi-configuration
  generator (such as Visual Studio Generators or "Xcode").

* The "INTERPROCEDURAL_OPTIMIZATION" target property is now enforced
  when enabled.  CMake will add IPO flags unconditionally or produce
  an error if it does not know the flags for the current compiler. The
  project is now responsible to use the "CheckIPOSupported" module to
  check for IPO support before enabling the target property.  See
  policy "CMP0069".

* The "WINDOWS_EXPORT_ALL_SYMBOLS" target property may now be used
  in combination with explicit ".def" files in order to export all
  symbols from the object files within a target plus an explicit list
  of symbols that the linker finds in dependencies (e.g.
  "msvcrt.lib").


Modules
-------

* A "CheckIPOSupported" module was added to help projects check
  whether interprocedural optimization (IPO) is supported by the
  current toolchain and CMake version.

* The "CMakeFindDependencyMacro" module "find_dependency" macro now
  forwards all arguments to the underlying "find_package()" call.
  Existing uses will continue to function as before, but callers can
  now access the full suite of arguments that "find_package" accepts.

* The "FeatureSummary" module "feature_summary()" command now
  accepts the new "DEFAULT_DESCRIPTION" option that will print the
  default title for the selected package type.

* The "FeatureSummary" module gained a new
  "FeatureSummary_<TYPE>_DESCRIPTION" variable that can be defined for
  each "<TYPE>" to replace the type name with the specified string
  whenever the package type is used in an output string by the module.

* The "FindDoxygen" module learned to control Doxygen behavior using
  CMake variables and generate documentation via the newly added
  "doxygen_add_docs()" function. The Doxygen input file ("Doxyfile")
  is automatically generated and doxygen is run as part of a custom
  target. Additional components can be specified to find optional
  tools: "dot", "mscgen" and "dia".

* The "FindMPI" module now provides imported targets.

* The "FindProtobuf" module "protobuf_generate_cpp()" command gained
  an "EXPORT_MACRO" option to specify the name of a DLL export markup
  macro.

* The "FindProtobuf" module now supports usage of static libraries
  for Unix via a new "Protobuf_USE_STATIC_LIBS" input variable.

* The "FindProtobuf" module now provides imported targets when the
  libraries are found.

* A new "GoogleTest" module was added to provide the
  "gtest_add_tests()" function independently of the "FindGTest"
  module. The function was also updated to support keyword arguments,
  with functionality expanded to allow a test name prefix and suffix
  to be specified, the dependency on the source files to be optional
  and the list of discovered test cases to be returned to the caller.


CTest
-----

* The "ctest_submit()" command gained a "HTTPHEADER" option to
  specify custom headers to send during submission.

* The "ctest(1)" executable gained new options which allow the
  developer to disable automatically adding tests to the test set to
  satisfy fixture dependencies. "-FS" prevents adding setup tests for
  fixtures matching the provided regular expression, "-FC" prevents
  adding cleanup tests for matching fixtures and "-FA" prevents adding
  any test for matching fixtures.

* A "DISABLED" test property was added to mark tests that are
  configured but explicitly disabled so they do not run.


CPack
-----

* The "CPackArchive" module learned to modify the filename per-
  component.  See the "CPACK_ARCHIVE_FILE_NAME" variable and its per-
  component version "CPACK_ARCHIVE_<component>_FILE_NAME".

* The "CPackComponent" module "cpack_add_component()" command gained
  a new "PLIST <filename>" option to specify the "pkgbuild" "--
  component-plist" argument when using the "productbuild" generator.

* The "CPackIFW" module "cpack_ifw_configure_component()" and
  "cpack_ifw_configure_component_group()" commands gained
  internationalization support for "DISPLAY_NAME" and "DESCRIPTION"
  options.

* The "CPackIFW" module learned the new hint "CPACK_IFW_ROOT"
  variable for finding the QtIFW tool suite installed in a non-
  standard place.

* The "CPackProductBuild" module gained a new
  "CPACK_PRODUCTBUILD_RESOURCES_DIR" variable to specify resources to
  be copied into the "Resources" directory.

* The "CPackRPM" module learned to modify the "debuginfo" package
  name.  See the "CPACK_RPM_DEBUGINFO_FILE_NAME" variable.

* The "CPackWIX" module patching system now has the ability to set
  additional attributes.  This can be done by specifying attributes
  with the "CPackWiXFragment" XML tag after the "Id" attribute. See
  the "CPACK_WIX_PATCH_FILE" variable.

* The CPack WIX generator implemented a new
  "CPACK_WIX_ROOT_FOLDER_ID" variable which allows using a custom root
  folder ID instead of the default "ProgramFilesFolder" /
  "ProgramFiles64Folder".


Other
-----

* Interprocedural optimization (IPO) is now supported for GNU and
  Clang compilers using link time optimization (LTO) flags.  See the
  "INTERPROCEDURAL_OPTIMIZATION" target property and
  "CheckIPOSupported" module.

* The "TARGET_OBJECTS" "generator expression" is now supported by
  the "add_custom_command()" and "file(GENERATE)" commands.

* Two new informational generator expressions to retrieve Apple
  Bundle directories have been added. The first one
  "$<TARGET_BUNDLE_DIR:tgt>" outputs the full path to the Bundle
  directory, the other one "$<TARGET_BUNDLE_CONTENT_DIR:tgt>" outputs
  the full path to the "Contents" directory of macOS Bundles and App
  Bundles. For all other bundle types and SDKs it is identical with
  "$<TARGET_BUNDLE_DIR:tgt>". The new expressions are helpful to query
  Bundle locations independent of the different Bundle types and
  layouts on macOS and iOS.


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

* An explicit deprecation diagnostic was added for policies
  "CMP0036" and below.  The "cmake-policies(7)" manual explains that
  the OLD behaviors of all policies are deprecated and that projects
  should always port to the NEW behaviors as soon as possible.

* The "Visual Studio 8 2005" generator is now deprecated and will be
  removed in a future version of CMake.

* The "Visual Studio 7 .NET 2003" generator has been removed.

* The "Xcode" generator dropped support for Xcode versions older
  than 3.

* The "FindDoxygen" module has deprecated several variables.

* The version of curl bundled with CMake no longer accepts URLs of
  the form "file://c:/..." on Windows due to a change in upstream curl
  7.52.  Use the form "file:///c:/..." instead to work on all
  versions.


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

* When using "AUTOMOC", CMake now scans for the presence of the
  "Q_PLUGIN_METADATA" macro and reruns moc when the file from the
  macro's "FILE" argument changes.

* When "AUTOMOC" detects an include statement of the form "#include
  "moc_<basename>.cpp"" the search for the respective header file now
  looks in the "INCLUDE_DIRECTORIES" of the target as well.

* When running tests, CTest learned to treat skipped tests (using
  the "SKIP_RETURN_CODE" property) the same as tests with the new
  "DISABLED" property. Due to this change, CTest will not indicate
  failure when all tests are either skipped or pass.

* The "Ninja" generator has loosened the dependencies of object
  compilation.  Object compilation now depends only on custom targets
  and custom commands associated with libraries on which the object's
  target depends and no longer depends on the libraries themselves.
  Source files in dependent targets may now compile without waiting
  for their targets' dependencies to link.

* On macOS, the default application bundle "Info.plist" file now
  enables Hi-DPI support.

* On macOS, "RPATH" settings such as "BUILD_WITH_INSTALL_RPATH" no
  longer affect the "install_name" field.  See policy "CMP0068".

----------------------------------------------------------------------------
Changes made since CMake 3.9.0-rc1:

Brad King (2):
      Autogen: Do not use per-config file suffixes with VS yet
      CMake 3.9.0-rc2

Konstantin Podsvirov (1):
      FindDoxygen: Restore DOXYGEN_DOT_FOUND variable

Matthew Woehlke (1):
      Help: Add 3.9 release note about find_dependency update

Walter Gray (1):
      C++ feature checks: Do not match "0 Warning(s)" as a warning

From bobburton at cs.arizona.edu  Thu Jun  8 16:34:29 2017
From: bobburton at cs.arizona.edu (Bob Burton)
Date: Thu, 8 Jun 2017 13:34:29 -0700
Subject: [cmake-developers] looking for linkls
Message-ID: <CABcgY30fDBJFNbFqJDzQYB-ac1V1kqH86QZBSmjjzp8xpCkCWg@mail.gmail.com>

Hi,

I'm trying to write autopkg recipes for some of the OS X apps we use in our
classes.  Any chance you could add dev, latest, and previous links to
https://cmake.org/files/, corresponding to the "Release Candidate", "Latest
Release", and "Previous Release" links on https://cmake.org/download/?

Thanks,
Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170608/d0ac0fe4/attachment.html>

From brad.king at kitware.com  Fri Jun  9 09:22:49 2017
From: brad.king at kitware.com (Brad King)
Date: Fri, 9 Jun 2017 09:22:49 -0400
Subject: [cmake-developers] looking for linkls
In-Reply-To: <CABcgY30fDBJFNbFqJDzQYB-ac1V1kqH86QZBSmjjzp8xpCkCWg@mail.gmail.com>
References: <CABcgY30fDBJFNbFqJDzQYB-ac1V1kqH86QZBSmjjzp8xpCkCWg@mail.gmail.com>
Message-ID: <16e8eb79-e200-dfb1-d4d2-35ee9f05e9c1@kitware.com>

On 06/08/2017 04:34 PM, Bob Burton wrote:
> I'm trying to write autopkg recipes for some of the OS X apps we
> use in our classes.  Any chance you could add dev, latest, and
> previous links to https://cmake.org/files/, corresponding to the
> "Release Candidate", "Latest Release", and "Previous Release"
> links on https://cmake.org/download/?

In order to make the proposal more concrete, please list example
URLs that you would like to see made to work and explain to what
they would link currently.

Thanks,
-Brad


From alex.merry at kde.org  Mon Jun 12 07:07:42 2017
From: alex.merry at kde.org (Alex Merry)
Date: Mon, 12 Jun 2017 12:07:42 +0100
Subject: [cmake-developers] Question about ALIAS targets
In-Reply-To: <oh4jdh$jr7$1@blaine.gmane.org>
References: <CAKME8fFHCexKXb0xpxbaodM13YSeE5j3xZfShbrawzWoigF9hQ@mail.gmail.com>
 <4a0dce85-afe1-248a-b349-649f3f4f1924@kitware.com>
 <oh4jdh$jr7$1@blaine.gmane.org>
Message-ID: <3925530.Pr87CBhDzG@aang>

On Monday, 5 June 2017 22:45:26 BST Stephen Kelly wrote:
> Brad King wrote:
> > Steve, is there any reason for the restriction other than not implementing
> > more use cases up front?
> 
> There may be more information in the mailing list archives, but as far as I
> remember, yes - we wanted to be conservative because we didn't know more
> use-cases. Additionally, we didn't know the impact of making the feature
> more unrestricted.

If you want to see an example use case, I found that c-ares were trying to ALIAS an 
IMPORTED library in their package config file to make it convenient for a downstream 
project to explicitly link against a static or shared library (if available), or link against "either" 
if they don't care:

https://github.com/c-ares/c-ares/blob/97f8b14c/c-ares-config.cmake.in

If c-ares is compiled with both static and shared options, it will produce c-ares::cares (shared) 
and c-ares::cares_static (static) exported targets. Otherwise, if only one of the static or shared 
options is specified, it will always just build and export a c-ares::cares target.

Obviously, the code won't work (and there is a pull request to fix it by using INTERFACE 
libraries at https://github.com/c-ares/c-ares/pull/108), and you may argue that this isn't the 
right solution to present downstreams with a "static vs shared vs don't care" choice, but I 
thought it might be interesting to show what developers are wanting to do with this.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170612/a17e37ba/attachment.html>

From bobburton at cs.arizona.edu  Mon Jun 12 13:16:52 2017
From: bobburton at cs.arizona.edu (Bob Burton)
Date: Mon, 12 Jun 2017 10:16:52 -0700
Subject: [cmake-developers] looking for linkls
In-Reply-To: <16e8eb79-e200-dfb1-d4d2-35ee9f05e9c1@kitware.com>
References: <CABcgY30fDBJFNbFqJDzQYB-ac1V1kqH86QZBSmjjzp8xpCkCWg@mail.gmail.com>
 <16e8eb79-e200-dfb1-d4d2-35ee9f05e9c1@kitware.com>
Message-ID: <CABcgY33r6WkJXpbezjT3ok607ggwjH2nuBmnmC1fq64WFDV7pA@mail.gmail.com>

Hi Brad,

It looks like the one link I really need is already there (LatestRelease),
but it isn't being maintained:


?
Current contents:


?
I'd like to see the contents match the "Latest Release" from
https://cmake.org/download/, which is currently 3.8.2.

This would be more helpful if it could be done automagically when the
download page is updated.  If it's likely to go stale, I'm better off
parsing the download page.

Thanks,
Bob

On Fri, Jun 9, 2017 at 6:22 AM, Brad King <brad.king at kitware.com> wrote:

> On 06/08/2017 04:34 PM, Bob Burton wrote:
> > I'm trying to write autopkg recipes for some of the OS X apps we
> > use in our classes.  Any chance you could add dev, latest, and
> > previous links to https://cmake.org/files/, corresponding to the
> > "Release Candidate", "Latest Release", and "Previous Release"
> > links on https://cmake.org/download/?
>
> In order to make the proposal more concrete, please list example
> URLs that you would like to see made to work and explain to what
> they would link currently.
>
> Thanks,
> -Brad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170612/20210c69/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: files.jpg
Type: image/jpeg
Size: 38137 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170612/20210c69/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: latest.jpg
Type: image/jpeg
Size: 96375 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170612/20210c69/attachment-0003.jpg>

From brad.king at kitware.com  Mon Jun 12 13:39:38 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 12 Jun 2017 13:39:38 -0400
Subject: [cmake-developers] looking for links
In-Reply-To: <CABcgY33r6WkJXpbezjT3ok607ggwjH2nuBmnmC1fq64WFDV7pA@mail.gmail.com>
References: <CABcgY30fDBJFNbFqJDzQYB-ac1V1kqH86QZBSmjjzp8xpCkCWg@mail.gmail.com>
 <16e8eb79-e200-dfb1-d4d2-35ee9f05e9c1@kitware.com>
 <CABcgY33r6WkJXpbezjT3ok607ggwjH2nuBmnmC1fq64WFDV7pA@mail.gmail.com>
Message-ID: <31a4020c-2eb2-7b1b-ad7e-7c39ea9631c7@kitware.com>

On 06/12/2017 01:16 PM, Bob Burton wrote:
> I'd like to see the contents match the "Latest Release" from
> https://cmake.org/download/, which is currently 3.8.2.

We've created these:

* https://cmake.org/files/ReleaseCandidate/
* https://cmake.org/files/LatestRelease/
* https://cmake.org/files/PreviousRelease/

> This would be more helpful if it could be done automagically when the
> download page is updated.

I've updated the instructions we use to maintain cmake.org to
include steps to update the above.

-Brad


From bobburton at cs.arizona.edu  Mon Jun 12 13:45:24 2017
From: bobburton at cs.arizona.edu (Bob Burton)
Date: Mon, 12 Jun 2017 10:45:24 -0700
Subject: [cmake-developers] looking for links
In-Reply-To: <31a4020c-2eb2-7b1b-ad7e-7c39ea9631c7@kitware.com>
References: <CABcgY30fDBJFNbFqJDzQYB-ac1V1kqH86QZBSmjjzp8xpCkCWg@mail.gmail.com>
 <16e8eb79-e200-dfb1-d4d2-35ee9f05e9c1@kitware.com>
 <CABcgY33r6WkJXpbezjT3ok607ggwjH2nuBmnmC1fq64WFDV7pA@mail.gmail.com>
 <31a4020c-2eb2-7b1b-ad7e-7c39ea9631c7@kitware.com>
Message-ID: <CABcgY318vdvS-2jLqxV1mX--XwckWDBRnDsgGGMoi6nzb3875A@mail.gmail.com>

Excellent--thanks!

On Mon, Jun 12, 2017 at 10:39 AM, Brad King <brad.king at kitware.com> wrote:

> On 06/12/2017 01:16 PM, Bob Burton wrote:
> > I'd like to see the contents match the "Latest Release" from
> > https://cmake.org/download/, which is currently 3.8.2.
>
> We've created these:
>
> * https://cmake.org/files/ReleaseCandidate/
> * https://cmake.org/files/LatestRelease/
> * https://cmake.org/files/PreviousRelease/
>
> > This would be more helpful if it could be done automagically when the
> > download page is updated.
>
> I've updated the instructions we use to maintain cmake.org to
> include steps to update the above.
>
> -Brad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170612/bf274dff/attachment.html>

From robert.maynard at kitware.com  Tue Jun 13 14:17:54 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 13 Jun 2017 14:17:54 -0400
Subject: [cmake-developers] CMake 3.9.0-rc3 is now ready for testing!
Message-ID: <CAFzjYVohA+PwyUhSMqvZVZ5061-=gxzsWCRxwEDgK+Kv7KEfrw@mail.gmail.com>

I am proud to announce the third CMake 3.9 release candidate.
  https://cmake.org/download/

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

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

Some of the more significant changes in CMake 3.9 are:

* "CUDA" is now supported by the Visual Studio Generators for VS
  2010 and above.  This complements the existing support by the
  Makefile Generators and the "Ninja" generator.

* The "add_library()" command "IMPORTED" option learned to support
  Object Libraries.

* All "find_" commands now have a "PACKAGE_ROOT" search path group
  that is first in the search heuristics.  If a "find_" command is
  called from inside a find module, then the CMake variable and
  environment variable named "<PackageName>_ROOT" are used as prefixes
  and are the first set of paths to be searched.

* The "install(TARGETS)" command learned a new "OBJECTS" option to
  specify where to install Object Libraries.

* The "install(EXPORT)" command learned how to export Object
  Libraries.

* A "BUILD_WITH_INSTALL_NAME_DIR" target property and corresponding
  "CMAKE_BUILD_WITH_INSTALL_NAME_DIR" variable were added to control
  whether to use the "INSTALL_NAME_DIR" target property value for
  binaries in the build tree.  This is for macOS "install_name" as
  "BUILD_WITH_INSTALL_RPATH" is for "RPATH".

* A "CUDA_PTX_COMPILATION" target property was added to Object
  Libraries to support compiling to ".ptx" files instead of host
  object files.

* A new "GoogleTest" module was added to provide the
  "gtest_add_tests()" function independently of the "FindGTest"
  module. The function was also updated to support keyword arguments,
  with functionality expanded to allow a test name prefix and suffix
  to be specified, the dependency on the source files to be optional
  and the list of discovered test cases to be returned to the caller.

* The "Ninja" generator has loosened the dependencies of object
  compilation.  Object compilation now depends only on custom targets
  and custom commands associated with libraries on which the object's
  target depends and no longer depends on the libraries themselves.
  Source files in dependent targets may now compile without waiting
  for their targets' dependencies to link.

* Interprocedural optimization (IPO) is now supported for GNU and
  Clang compilers using link time optimization (LTO) flags.  See the
  "INTERPROCEDURAL_OPTIMIZATION" target property and
  "CheckIPOSupported" module.

* The "TARGET_OBJECTS" "generator expression" is now supported by
  the "add_custom_command()" and "file(GENERATE)" commands.

CMake 3.9 Release Notes
***********************

Changes made since CMake 3.8 include the following.


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


Languages
---------

* "CUDA" is now supported by the Visual Studio Generators for VS
  2010 and above.  This complements the existing support by the
  Makefile Generators and the "Ninja" generator.


Generators
----------

* Visual Studio Generators for VS 2010 and above learned to support
  the "ASM_NASM" language when "nasm" is installed.

* The "Xcode" generator learned to create Xcode schema files. This
  is an experimental feature and can be activated by setting the
  "CMAKE_XCODE_GENERATE_SCHEME" variable to a "TRUE" value.


Commands
--------

* The "add_library()" command "IMPORTED" option learned to support
  Object Libraries.

* All "find_" commands now have a "PACKAGE_ROOT" search path group
  that is first in the search heuristics.  If a "find_" command is
  called from inside a find module, then the CMake variable and
  environment variable named "<PackageName>_ROOT" are used as prefixes
  and are the first set of paths to be searched.

* The "find_library()" command learned to search "libx32" paths when
  the build targets the "x32" ABI.  See the
  "FIND_LIBRARY_USE_LIBX32_PATHS" global property.

* The "include_external_msproject()" command learned to use the
  "MAP_IMPORTED_CONFIG_<CONFIG>" target property to map current
  configurations to the external configurations.

* The "install(TARGETS)" command learned a new "OBJECTS" option to
  specify where to install Object Libraries.

* The "install(EXPORT)" command learned how to export Object
  Libraries.

* The "project()" command learned an optional "DESCRIPTION"
  parameter to set the "PROJECT_DESCRIPTION" variable.

* The "separate_arguments()" command gained a "NATIVE_COMMAND" mode
  that performs argument separation depending on the host operating
  system.


Variables
---------

* A "CMAKE_ANDROID_NDK_DEPRECATED_HEADERS" variable was added for
  use when Cross Compiling for Android with the NDK to request use of
  the deprecated headers even when unified headers are available. The
  default is now to use unified headers if available.

* A "CMAKE_AUTOMOC_DEPEND_FILTERS" variable was introduced to allow
  "CMAKE_AUTOMOC" to extract additional dependency file names for
  "moc" from the contents of source files.

* A "CMAKE_AUTOUIC_SEARCH_PATHS" variable was introduced to allow
  "CMAKE_AUTOUIC" to search for "foo.ui" in more places than the
  vicinity of the file including "ui_foo.h".

* A "CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX" variable was added to
  tell the "find_library()" command to search in a "lib<suffix>"
  directory before each "lib" directory that would normally be
  searched.

* A "CMAKE_INTERPROCEDURAL_OPTIMIZATION" variable was added to
  initialize the "INTERPROCEDURAL_OPTIMIZATION" property on all
  targets.

* A "CMAKE_<LANG>_COMPILER_AR" variable was added to hold the path
  to the GCC/Clang wrapper of "ar".

* A "CMAKE_<LANG>_COMPILER_RANLIB" variable was added to hold the
  path to the GCC/Clang wrapper of "ranlib".

* The "CMAKE_SYSROOT_COMPILE" and "CMAKE_SYSROOT_LINK" variables
  were added to use separate sysroots for compiling and linking.


Properties
----------

* A new "AUTOGEN_BUILD_DIR" target property was introduced to set a
  custom output directory for "AUTOMOC", "AUTOUIC", and "AUTORCC".

* A new "AUTOMOC_DEPEND_FILTERS" target property was introduced to
  allow "AUTOMOC" to extract additional dependency file names for
  "moc" from the contents of source files.

* A new "AUTOUIC_SEARCH_PATHS" target property was introduced to
  allow "AUTOUIC" to search for "foo.ui" in more places than the
  vicinity of the file including "ui_foo.h".

* Global properties "AUTOGEN_SOURCE_GROUP", "AUTOMOC_SOURCE_GROUP"
  and "AUTORCC_SOURCE_GROUP" were introduced to allow files generated
  by "AUTOMOC" or "AUTORCC" to be placed in a "source_group()".

* A "BUILD_WITH_INSTALL_NAME_DIR" target property and corresponding
  "CMAKE_BUILD_WITH_INSTALL_NAME_DIR" variable were added to control
  whether to use the "INSTALL_NAME_DIR" target property value for
  binaries in the build tree.  This is for macOS "install_name" as
  "BUILD_WITH_INSTALL_RPATH" is for "RPATH".

* A "CUDA_PTX_COMPILATION" target property was added to Object
  Libraries to support compiling to ".ptx" files instead of host
  object files.

* A "GENERATOR_IS_MULTI_CONFIG" global property was added to
  determine whether the current generator is a multi-configuration
  generator (such as Visual Studio Generators or "Xcode").

* The "INTERPROCEDURAL_OPTIMIZATION" target property is now enforced
  when enabled.  CMake will add IPO flags unconditionally or produce
  an error if it does not know the flags for the current compiler. The
  project is now responsible to use the "CheckIPOSupported" module to
  check for IPO support before enabling the target property.  See
  policy "CMP0069".

* The "WINDOWS_EXPORT_ALL_SYMBOLS" target property may now be used
  in combination with explicit ".def" files in order to export all
  symbols from the object files within a target plus an explicit list
  of symbols that the linker finds in dependencies (e.g.
  "msvcrt.lib").


Modules
-------

* A "CheckIPOSupported" module was added to help projects check
  whether interprocedural optimization (IPO) is supported by the
  current toolchain and CMake version.

* The "CMakeFindDependencyMacro" module "find_dependency" macro now
  forwards all arguments to the underlying "find_package()" call.
  Existing uses will continue to function as before, but callers can
  now access the full suite of arguments that "find_package" accepts.

* The "FeatureSummary" module "feature_summary()" command now
  accepts the new "DEFAULT_DESCRIPTION" option that will print the
  default title for the selected package type.

* The "FeatureSummary" module gained a new
  "FeatureSummary_<TYPE>_DESCRIPTION" variable that can be defined for
  each "<TYPE>" to replace the type name with the specified string
  whenever the package type is used in an output string by the module.

* The "FindDoxygen" module learned to control Doxygen behavior using
  CMake variables and generate documentation via the newly added
  "doxygen_add_docs()" function. The Doxygen input file ("Doxyfile")
  is automatically generated and doxygen is run as part of a custom
  target. Additional components can be specified to find optional
  tools: "dot", "mscgen" and "dia".

* The "FindMPI" module now provides imported targets.

* The "FindProtobuf" module "protobuf_generate_cpp()" command gained
  an "EXPORT_MACRO" option to specify the name of a DLL export markup
  macro.

* The "FindProtobuf" module now supports usage of static libraries
  for Unix via a new "Protobuf_USE_STATIC_LIBS" input variable.

* The "FindProtobuf" module now provides imported targets when the
  libraries are found.

* A new "GoogleTest" module was added to provide the
  "gtest_add_tests()" function independently of the "FindGTest"
  module. The function was also updated to support keyword arguments,
  with functionality expanded to allow a test name prefix and suffix
  to be specified, the dependency on the source files to be optional
  and the list of discovered test cases to be returned to the caller.


CTest
-----

* The "ctest_submit()" command gained a "HTTPHEADER" option to
  specify custom headers to send during submission.

* The "ctest(1)" executable gained new options which allow the
  developer to disable automatically adding tests to the test set to
  satisfy fixture dependencies. "-FS" prevents adding setup tests for
  fixtures matching the provided regular expression, "-FC" prevents
  adding cleanup tests for matching fixtures and "-FA" prevents adding
  any test for matching fixtures.

* A "DISABLED" test property was added to mark tests that are
  configured but explicitly disabled so they do not run.


CPack
-----

* The "CPackArchive" module learned to modify the filename per-
  component.  See the "CPACK_ARCHIVE_FILE_NAME" variable and its per-
  component version "CPACK_ARCHIVE_<component>_FILE_NAME".

* The "CPackComponent" module "cpack_add_component()" command gained
  a new "PLIST <filename>" option to specify the "pkgbuild" "--
  component-plist" argument when using the "productbuild" generator.

* The "CPackIFW" module "cpack_ifw_configure_component()" and
  "cpack_ifw_configure_component_group()" commands gained
  internationalization support for "DISPLAY_NAME" and "DESCRIPTION"
  options.

* The "CPackIFW" module learned the new hint "CPACK_IFW_ROOT"
  variable for finding the QtIFW tool suite installed in a non-
  standard place.

* The "CPackProductBuild" module gained a new
  "CPACK_PRODUCTBUILD_RESOURCES_DIR" variable to specify resources to
  be copied into the "Resources" directory.

* The "CPackRPM" module learned to modify the "debuginfo" package
  name.  See the "CPACK_RPM_DEBUGINFO_FILE_NAME" variable.

* The "CPackWIX" module patching system now has the ability to set
  additional attributes.  This can be done by specifying attributes
  with the "CPackWiXFragment" XML tag after the "Id" attribute. See
  the "CPACK_WIX_PATCH_FILE" variable.

* The CPack WIX generator implemented a new
  "CPACK_WIX_ROOT_FOLDER_ID" variable which allows using a custom root
  folder ID instead of the default "ProgramFilesFolder" /
  "ProgramFiles64Folder".


Other
-----

* Interprocedural optimization (IPO) is now supported for GNU and
  Clang compilers using link time optimization (LTO) flags.  See the
  "INTERPROCEDURAL_OPTIMIZATION" target property and
  "CheckIPOSupported" module.

* The "TARGET_OBJECTS" "generator expression" is now supported by
  the "add_custom_command()" and "file(GENERATE)" commands.

* Two new informational generator expressions to retrieve Apple
  Bundle directories have been added. The first one
  "$<TARGET_BUNDLE_DIR:tgt>" outputs the full path to the Bundle
  directory, the other one "$<TARGET_BUNDLE_CONTENT_DIR:tgt>" outputs
  the full path to the "Contents" directory of macOS Bundles and App
  Bundles. For all other bundle types and SDKs it is identical with
  "$<TARGET_BUNDLE_DIR:tgt>". The new expressions are helpful to query
  Bundle locations independent of the different Bundle types and
  layouts on macOS and iOS.


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

* An explicit deprecation diagnostic was added for policies
  "CMP0036" and below.  The "cmake-policies(7)" manual explains that
  the OLD behaviors of all policies are deprecated and that projects
  should always port to the NEW behaviors as soon as possible.

* The "Visual Studio 8 2005" generator is now deprecated and will be
  removed in a future version of CMake.

* The "Visual Studio 7 .NET 2003" generator has been removed.

* The "Xcode" generator dropped support for Xcode versions older
  than 3.

* The "FindDoxygen" module has deprecated several variables.

* The version of curl bundled with CMake no longer accepts URLs of
  the form "file://c:/..." on Windows due to a change in upstream curl
  7.52.  Use the form "file:///c:/..." instead to work on all
  versions.


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

* When using "AUTOMOC", CMake now scans for the presence of the
  "Q_PLUGIN_METADATA" macro and reruns moc when the file from the
  macro's "FILE" argument changes.

* When "AUTOMOC" detects an include statement of the form "#include
  "moc_<basename>.cpp"" the search for the respective header file now
  looks in the "INCLUDE_DIRECTORIES" of the target as well.

* When running tests, CTest learned to treat skipped tests (using
  the "SKIP_RETURN_CODE" property) the same as tests with the new
  "DISABLED" property. Due to this change, CTest will not indicate
  failure when all tests are either skipped or pass.

* The "Ninja" generator has loosened the dependencies of object
  compilation.  Object compilation now depends only on custom targets
  and custom commands associated with libraries on which the object's
  target depends and no longer depends on the libraries themselves.
  Source files in dependent targets may now compile without waiting
  for their targets' dependencies to link.

* On macOS, the default application bundle "Info.plist" file now
  enables Hi-DPI support.

* On macOS, "RPATH" settings such as "BUILD_WITH_INSTALL_RPATH" no
  longer affect the "install_name" field.  See policy "CMP0068".

----------------------------------------------------------------------------
Changes made since CMake 3.9.0-rc2:

Brad King (6):
      C++ feature checks: Improve exclusion of "0 Warning(s)"
      FindDoxygen: Create imported targets at most once in a given scope
      Android: Detect API version of standalone toolchain with unified headers
      Android: Do not pass sysroot include for standalone toolchain
      Android: Add support for unified headers
      CMake 3.9.0-rc3

Robert Maynard (1):
      CUDA: When linking device code suppress CUDA 8.0+ deprecation warnings

Rolf Eike Beer (2):
      FindPkgConfig: fix confusing indentation
      FindPkgConfig: mention that variables will be ;-lists

From daniel at pfeifer-mail.de  Sun Jun 18 11:34:39 2017
From: daniel at pfeifer-mail.de (Daniel Pfeifer)
Date: Sun, 18 Jun 2017 17:34:39 +0200
Subject: [cmake-developers] CMake PCH Prototype
Message-ID: <CANZMcXoXrb_faWmiNtvfcOEKL0yKeXBfFtqaQW9JyEg9k2tu2g@mail.gmail.com>

Hi Julian,

I have rebased my old precompiled-headers branch on master and created a
work-in-progress merge-request here:
https://gitlab.kitware.com/cmake/cmake/merge_requests/984

Cheers, Daniel


2017-06-15 13:38 GMT+02:00 Julian Landesberger <j.landesberger at gmail.com>:

> Hallo Daniel,
>
> wir hatten uns nach deinem Meetup-Vortrag letzte Woche kurz ?ber die
> Verwaltung von precompiled headers in CMake unterhalten. Du meintest
> damals, du h?ttest bereits eine Art Prototyp daf?r geschrieben, der aber
> noch nicht an "gro?en" Projekten getestet wurde, und, dass du ihn daf?r zur
> Verf?gung stellen k?nntest.
> Ich w?rde den Prototypen gerne am Simulationscode des Lehrstuhls f?r
> Computation in Engineering der TU M?nchen ausprobieren. Der hat immerhin
> ?ber 6000 source- und header-Dateien, ist also kein kompaktes
> Beispielprojekt mehr.
>
> W?rde mich freuen wenn wir da was machen k?nnten und beste Gr??e!
>
> Julian Landesberger
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170618/02179abf/attachment.html>

From alexander.stein at systec-electronic.com  Mon Jun 19 11:35:58 2017
From: alexander.stein at systec-electronic.com (Alexander Stein)
Date: Mon, 19 Jun 2017 17:35:58 +0200
Subject: [cmake-developers] [PATCH 1/1] Add binutils' size to list of
	variables
Message-ID: <20170619153558.14470-1-alexander.stein@systec-electronic.com>

In case there is no native size tool (e.g. on Windows) a binutils
toolchain provides this. Create a variable for it.

Signed-off-by: Alexander Stein <alexander.stein at systec-electronic.com>
---
 Modules/CMakeFindBinUtils.cmake | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Modules/CMakeFindBinUtils.cmake b/Modules/CMakeFindBinUtils.cmake
index e4103d0b7c..3c41498874 100644
--- a/Modules/CMakeFindBinUtils.cmake
+++ b/Modules/CMakeFindBinUtils.cmake
@@ -57,8 +57,9 @@ else()
   find_program(CMAKE_NM NAMES ${_CMAKE_TOOLCHAIN_PREFIX}nm HINTS ${_CMAKE_TOOLCHAIN_LOCATION})
   find_program(CMAKE_OBJDUMP NAMES ${_CMAKE_TOOLCHAIN_PREFIX}objdump HINTS ${_CMAKE_TOOLCHAIN_LOCATION})
   find_program(CMAKE_OBJCOPY NAMES ${_CMAKE_TOOLCHAIN_PREFIX}objcopy HINTS ${_CMAKE_TOOLCHAIN_LOCATION})
+  find_program(CMAKE_SIZE NAMES ${_CMAKE_TOOLCHAIN_PREFIX}size HINTS ${_CMAKE_TOOLCHAIN_LOCATION})
 
-  mark_as_advanced(CMAKE_AR CMAKE_RANLIB CMAKE_STRIP CMAKE_LINKER CMAKE_NM CMAKE_OBJDUMP CMAKE_OBJCOPY)
+  mark_as_advanced(CMAKE_AR CMAKE_RANLIB CMAKE_STRIP CMAKE_LINKER CMAKE_NM CMAKE_OBJDUMP CMAKE_OBJCOPY CMAKE_SIZE)
 
 endif()
 
-- 
2.13.0


From brad.king at kitware.com  Mon Jun 19 13:08:34 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 19 Jun 2017 13:08:34 -0400
Subject: [cmake-developers] [PATCH 1/1] Add binutils' size to list of
 variables
In-Reply-To: <20170619153558.14470-1-alexander.stein@systec-electronic.com>
References: <20170619153558.14470-1-alexander.stein@systec-electronic.com>
Message-ID: <07c067fc-a977-d9de-273d-1d6191b6300d@kitware.com>

On 06/19/2017 11:35 AM, Alexander Stein wrote:
> In case there is no native size tool (e.g. on Windows) a binutils
> toolchain provides this. Create a variable for it.

Thanks.  Please see `CONTRIBUTING.rst` for the preferred contribution
path and open a merge request on our GitLab instance
(gitlab.kitware.com/cmake/cmake).

Thanks,
-Brad


From robert.maynard at kitware.com  Thu Jun 22 13:37:33 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 22 Jun 2017 13:37:33 -0400
Subject: [cmake-developers] [ANNOUNCE] CMake 3.9.0-rc4 is now ready for
	testing!
Message-ID: <CAFzjYVp_uU49ibyz6QyOfFceOAk9BEqYFm2ZEE3s7HOOkYpFUg@mail.gmail.com>

I am proud to announce the fourth CMake 3.9 release candidate.
  https://cmake.org/download/

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

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

Some of the more significant changes in CMake 3.9 are:

* "CUDA" is now supported by the Visual Studio Generators for VS
  2010 and above.  This complements the existing support by the
  Makefile Generators and the "Ninja" generator. CUDA 8.0.61 or higher
  is recommended due to known bugs in the VS integration by earlier
  versions.

* CMake is now aware of the "C++ standards" and "C standards" and
  their associated meta-features for the following "compiler ids":
  "Cray", "PGI", and "XL".

* The "add_library()" command "IMPORTED" option learned to support
  Object Libraries.

* All "find_" commands now have a "PACKAGE_ROOT" search path group
  that is first in the search heuristics.  If a "find_" command is
  called from inside a find module, then the CMake variable and
  environment variable named "<PackageName>_ROOT" are used as prefixes
  and are the first set of paths to be searched.

* The "install(TARGETS)" command learned a new "OBJECTS" option to
  specify where to install Object Libraries.

* The "install(EXPORT)" command learned how to export Object
  Libraries.

* A "BUILD_WITH_INSTALL_NAME_DIR" target property and corresponding
  "CMAKE_BUILD_WITH_INSTALL_NAME_DIR" variable were added to control
  whether to use the "INSTALL_NAME_DIR" target property value for
  binaries in the build tree.  This is for macOS "install_name" as
  "BUILD_WITH_INSTALL_RPATH" is for "RPATH".

* A "CUDA_PTX_COMPILATION" target property was added to Object
  Libraries to support compiling to ".ptx" files instead of host
  object files.

* A new "GoogleTest" module was added to provide the
  "gtest_add_tests()" function independently of the "FindGTest"
  module. The function was also updated to support keyword arguments,
  with functionality expanded to allow a test name prefix and suffix
  to be specified, the dependency on the source files to be optional
  and the list of discovered test cases to be returned to the caller.

* The "Ninja" generator has loosened the dependencies of object
  compilation.  Object compilation now depends only on custom targets
  and custom commands associated with libraries on which the object's
  target depends and no longer depends on the libraries themselves.
  Source files in dependent targets may now compile without waiting
  for their targets' dependencies to link.

* Interprocedural optimization (IPO) is now supported for GNU and
  Clang compilers using link time optimization (LTO) flags.  See the
  "INTERPROCEDURAL_OPTIMIZATION" target property and
  "CheckIPOSupported" module.

* The "TARGET_OBJECTS" "generator expression" is now supported by
  the "add_custom_command()" and "file(GENERATE)" commands.

CMake 3.9 Release Notes
***********************

Changes made since CMake 3.8 include the following.


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


Languages
---------

* "CUDA" is now supported by the Visual Studio Generators for VS
  2010 and above.  This complements the existing support by the
  Makefile Generators and the "Ninja" generator. CUDA 8.0.61 or higher
  is recommended due to known bugs in the VS integration by earlier
  versions.

* CMake is now aware of the "C++ standards" and "C standards" and
  their associated meta-features for the following "compiler ids":
  "Cray", "PGI", and "XL".


Generators
----------

* Visual Studio Generators for VS 2010 and above learned to support
  the "ASM_NASM" language when "nasm" is installed.

* The "Xcode" generator learned to create Xcode schema files. This
  is an experimental feature and can be activated by setting the
  "CMAKE_XCODE_GENERATE_SCHEME" variable to a "TRUE" value.


Commands
--------

* The "add_library()" command "IMPORTED" option learned to support
  Object Libraries.

* All "find_" commands now have a "PACKAGE_ROOT" search path group
  that is first in the search heuristics.  If a "find_" command is
  called from inside a find module, then the CMake variable and
  environment variable named "<PackageName>_ROOT" are used as prefixes
  and are the first set of paths to be searched.

* The "find_library()" command learned to search "libx32" paths when
  the build targets the "x32" ABI.  See the
  "FIND_LIBRARY_USE_LIBX32_PATHS" global property.

* The "include_external_msproject()" command learned to use the
  "MAP_IMPORTED_CONFIG_<CONFIG>" target property to map current
  configurations to the external configurations.

* The "install(TARGETS)" command learned a new "OBJECTS" option to
  specify where to install Object Libraries.

* The "install(EXPORT)" command learned how to export Object
  Libraries.

* The "project()" command learned an optional "DESCRIPTION"
  parameter to set the "PROJECT_DESCRIPTION" variable.

* The "separate_arguments()" command gained a "NATIVE_COMMAND" mode
  that performs argument separation depending on the host operating
  system.


Variables
---------

* A "CMAKE_ANDROID_NDK_DEPRECATED_HEADERS" variable was added for
  use when Cross Compiling for Android with the NDK to request use of
  the deprecated headers even when unified headers are available. The
  default is now to use unified headers if available.

* A "CMAKE_AUTOMOC_DEPEND_FILTERS" variable was introduced to allow
  "CMAKE_AUTOMOC" to extract additional dependency file names for
  "moc" from the contents of source files.

* A "CMAKE_AUTOUIC_SEARCH_PATHS" variable was introduced to allow
  "CMAKE_AUTOUIC" to search for "foo.ui" in more places than the
  vicinity of the file including "ui_foo.h".

* A "CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX" variable was added to
  tell the "find_library()" command to search in a "lib<suffix>"
  directory before each "lib" directory that would normally be
  searched.

* A "CMAKE_INTERPROCEDURAL_OPTIMIZATION" variable was added to
  initialize the "INTERPROCEDURAL_OPTIMIZATION" property on all
  targets.

* A "CMAKE_<LANG>_COMPILER_AR" variable was added to hold the path
  to the GCC/Clang wrapper of "ar".

* A "CMAKE_<LANG>_COMPILER_RANLIB" variable was added to hold the
  path to the GCC/Clang wrapper of "ranlib".

* The "CMAKE_SYSROOT_COMPILE" and "CMAKE_SYSROOT_LINK" variables
  were added to use separate sysroots for compiling and linking.


Properties
----------

* A new "AUTOGEN_BUILD_DIR" target property was introduced to set a
  custom output directory for "AUTOMOC", "AUTOUIC", and "AUTORCC".

* A new "AUTOMOC_DEPEND_FILTERS" target property was introduced to
  allow "AUTOMOC" to extract additional dependency file names for
  "moc" from the contents of source files.

* A new "AUTOUIC_SEARCH_PATHS" target property was introduced to
  allow "AUTOUIC" to search for "foo.ui" in more places than the
  vicinity of the file including "ui_foo.h".

* Global properties "AUTOGEN_SOURCE_GROUP", "AUTOMOC_SOURCE_GROUP"
  and "AUTORCC_SOURCE_GROUP" were introduced to allow files generated
  by "AUTOMOC" or "AUTORCC" to be placed in a "source_group()".

* A "BUILD_WITH_INSTALL_NAME_DIR" target property and corresponding
  "CMAKE_BUILD_WITH_INSTALL_NAME_DIR" variable were added to control
  whether to use the "INSTALL_NAME_DIR" target property value for
  binaries in the build tree.  This is for macOS "install_name" as
  "BUILD_WITH_INSTALL_RPATH" is for "RPATH".

* A "CUDA_PTX_COMPILATION" target property was added to Object
  Libraries to support compiling to ".ptx" files instead of host
  object files.

* A "GENERATOR_IS_MULTI_CONFIG" global property was added to
  determine whether the current generator is a multi-configuration
  generator (such as Visual Studio Generators or "Xcode").

* The "INTERPROCEDURAL_OPTIMIZATION" target property is now enforced
  when enabled.  CMake will add IPO flags unconditionally or produce
  an error if it does not know the flags for the current compiler. The
  project is now responsible to use the "CheckIPOSupported" module to
  check for IPO support before enabling the target property.  See
  policy "CMP0069".

* The "WINDOWS_EXPORT_ALL_SYMBOLS" target property may now be used
  in combination with explicit ".def" files in order to export all
  symbols from the object files within a target plus an explicit list
  of symbols that the linker finds in dependencies (e.g.
  "msvcrt.lib").


Modules
-------

* A "CheckIPOSupported" module was added to help projects check
  whether interprocedural optimization (IPO) is supported by the
  current toolchain and CMake version.

* The "CMakeFindDependencyMacro" module "find_dependency" macro now
  forwards all arguments to the underlying "find_package()" call.
  Existing uses will continue to function as before, but callers can
  now access the full suite of arguments that "find_package" accepts.

* The "FeatureSummary" module "feature_summary()" command now
  accepts the new "DEFAULT_DESCRIPTION" option that will print the
  default title for the selected package type.

* The "FeatureSummary" module gained a new
  "FeatureSummary_<TYPE>_DESCRIPTION" variable that can be defined for
  each "<TYPE>" to replace the type name with the specified string
  whenever the package type is used in an output string by the module.

* The "FindDoxygen" module learned to control Doxygen behavior using
  CMake variables and generate documentation via the newly added
  "doxygen_add_docs()" function. The Doxygen input file ("Doxyfile")
  is automatically generated and doxygen is run as part of a custom
  target. Additional components can be specified to find optional
  tools: "dot", "mscgen" and "dia".

* The "FindMPI" module now provides imported targets.

* The "FindProtobuf" module "protobuf_generate_cpp()" command gained
  an "EXPORT_MACRO" option to specify the name of a DLL export markup
  macro.

* The "FindProtobuf" module now supports usage of static libraries
  for Unix via a new "Protobuf_USE_STATIC_LIBS" input variable.

* The "FindProtobuf" module now provides imported targets when the
  libraries are found.

* A new "GoogleTest" module was added to provide the
  "gtest_add_tests()" function independently of the "FindGTest"
  module. The function was also updated to support keyword arguments,
  with functionality expanded to allow a test name prefix and suffix
  to be specified, the dependency on the source files to be optional
  and the list of discovered test cases to be returned to the caller.


CTest
-----

* The "ctest_submit()" command gained a "HTTPHEADER" option to
  specify custom headers to send during submission.

* The "ctest(1)" executable gained new options which allow the
  developer to disable automatically adding tests to the test set to
  satisfy fixture dependencies. "-FS" prevents adding setup tests for
  fixtures matching the provided regular expression, "-FC" prevents
  adding cleanup tests for matching fixtures and "-FA" prevents adding
  any test for matching fixtures.

* A "DISABLED" test property was added to mark tests that are
  configured but explicitly disabled so they do not run.


CPack
-----

* The "CPackArchive" module learned to modify the filename per-
  component.  See the "CPACK_ARCHIVE_FILE_NAME" variable and its per-
  component version "CPACK_ARCHIVE_<component>_FILE_NAME".

* The "CPackComponent" module "cpack_add_component()" command gained
  a new "PLIST <filename>" option to specify the "pkgbuild" "--
  component-plist" argument when using the "productbuild" generator.

* The "CPackIFW" module "cpack_ifw_configure_component()" and
  "cpack_ifw_configure_component_group()" commands gained
  internationalization support for "DISPLAY_NAME" and "DESCRIPTION"
  options.

* The "CPackIFW" module learned the new hint "CPACK_IFW_ROOT"
  variable for finding the QtIFW tool suite installed in a non-
  standard place.

* The "CPackProductBuild" module gained a new
  "CPACK_PRODUCTBUILD_RESOURCES_DIR" variable to specify resources to
  be copied into the "Resources" directory.

* The "CPackRPM" module learned to modify the "debuginfo" package
  name.  See the "CPACK_RPM_DEBUGINFO_FILE_NAME" variable.

* The "CPackWIX" module patching system now has the ability to set
  additional attributes.  This can be done by specifying attributes
  with the "CPackWiXFragment" XML tag after the "Id" attribute. See
  the "CPACK_WIX_PATCH_FILE" variable.

* The CPack WIX generator implemented a new
  "CPACK_WIX_ROOT_FOLDER_ID" variable which allows using a custom root
  folder ID instead of the default "ProgramFilesFolder" /
  "ProgramFiles64Folder".


Other
-----

* Interprocedural optimization (IPO) is now supported for GNU and
  Clang compilers using link time optimization (LTO) flags.  See the
  "INTERPROCEDURAL_OPTIMIZATION" target property and
  "CheckIPOSupported" module.

* The "TARGET_OBJECTS" "generator expression" is now supported by
  the "add_custom_command()" and "file(GENERATE)" commands.

* Two new informational generator expressions to retrieve Apple
  Bundle directories have been added. The first one
  "$<TARGET_BUNDLE_DIR:tgt>" outputs the full path to the Bundle
  directory, the other one "$<TARGET_BUNDLE_CONTENT_DIR:tgt>" outputs
  the full path to the "Contents" directory of macOS Bundles and App
  Bundles. For all other bundle types and SDKs it is identical with
  "$<TARGET_BUNDLE_DIR:tgt>". The new expressions are helpful to query
  Bundle locations independent of the different Bundle types and
  layouts on macOS and iOS.


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

* An explicit deprecation diagnostic was added for policies
  "CMP0036" and below.  The "cmake-policies(7)" manual explains that
  the OLD behaviors of all policies are deprecated and that projects
  should always port to the NEW behaviors as soon as possible.

* The "Visual Studio 8 2005" generator is now deprecated and will be
  removed in a future version of CMake.

* The "Visual Studio 7 .NET 2003" generator has been removed.

* The "Xcode" generator dropped support for Xcode versions older
  than 3.

* The "FindDoxygen" module has deprecated several variables.

* The version of curl bundled with CMake no longer accepts URLs of
  the form "file://c:/..." on Windows due to a change in upstream curl
  7.52.  Use the form "file:///c:/..." instead to work on all
  versions.


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

* When using "AUTOMOC", CMake now scans for the presence of the
  "Q_PLUGIN_METADATA" macro and reruns moc when the file from the
  macro's "FILE" argument changes.

* When "AUTOMOC" detects an include statement of the form "#include
  "moc_<basename>.cpp"" the search for the respective header file now
  looks in the "INCLUDE_DIRECTORIES" of the target as well.

* When running tests, CTest learned to treat skipped tests (using
  the "SKIP_RETURN_CODE" property) the same as tests with the new
  "DISABLED" property. Due to this change, CTest will not indicate
  failure when all tests are either skipped or pass.

* The "Ninja" generator has loosened the dependencies of object
  compilation.  Object compilation now depends only on custom targets
  and custom commands associated with libraries on which the object's
  target depends and no longer depends on the libraries themselves.
  Source files in dependent targets may now compile without waiting
  for their targets' dependencies to link.

* On macOS, the default application bundle "Info.plist" file now
  enables Hi-DPI support.

* On macOS, "RPATH" settings such as "BUILD_WITH_INSTALL_RPATH" no
  longer affect the "install_name" field.  See policy "CMP0068".

----------------------------------------------------------------------------
Changes made since CMake 3.9.0-rc3:

Brad King (14):
      README: Update list of supported platforms
      IPO: Consider support for each language separately
      curl: Update script to get curl 7.54.1
      cmake: Fix default file translate mode when using libuv
      Help: Fix typo in Cray/PGI/XL compile features docs
      Help: Document that VS 2017 compile features are recorded
      expat: Update script to get Expat 2.2.1
      expat: Fix compilation on systems without stdint.h
      Help: Update 3.9 release notes with recommended CUDA version for VS
      VS: Fix target_compile_options for CUDA
      VS: Improve workaround for CUDA -Xcompiler placement bug
      Android: Fix include path for unified headers
      VS: Fix support for rc /nologo flag in per-source COMPILE_FLAGS
      CMake 3.9.0-rc4

Chuck Atkins (1):
      Help: Add docs for new compilers supporting language standards.

Curl Upstream (1):
      curl 2017-06-14 (54b636f1)

Expat Upstream (1):
      expat 2017-06-17 (c4446687)

Michael St?rmer (1):
      Vs: allow CSharp targets to be linked to CXX targets

From rcdailey.lists at gmail.com  Fri Jun 23 15:18:34 2017
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Fri, 23 Jun 2017 14:18:34 -0500
Subject: [cmake-developers] Bug with CMAKE_ASM_COMPILER and Android NDK
Message-ID: <CAHd499CKYZ=97MJJRd3oOyjQLvCWSrUR2Ssa=wcWLizisBQdzQ@mail.gmail.com>

So I have two environment variables:

ANDROID_NDK = E:\android\ndk
ANDROID_NDK_72 = E:\android\ndk_72

In my toolchain file, I do this:



set( CMAKE_SYSTEM_NAME Android )
set( CMAKE_SYSTEM_VERSION 15 ) # API level
set( CMAKE_ANDROID_ARCH_ABI armeabi-v7a )
set( CMAKE_ANDROID_STL_TYPE c++_shared )
set( CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION clang )

# ANDROID_NDK_72 represents a separate path to the NDK for 7.2 frontend
# builds and later. This is to make it less painful to convert between
# Crystax (7.1.x) and official NDK, which was restored in version 7.2.
string(REGEX REPLACE "\\\\" "/" ndk_path "$ENV{ANDROID_NDK_72}")
if( NOT EXISTS ${ndk_path} )
    string(REGEX REPLACE "\\\\" "/" ndk_path "$ENV{ANDROID_NDK}")
endif()

set( CMAKE_ANDROID_NDK ${ndk_path} )
unset(ndk_path)



This works fine, until you do something like this in your CMake scripts:


enable_language(ASM)


CMake appears to find clang.exe in the wrong place (It's using
ANDROID_NDK directly somehow instead of using the CMAKE_ANDROID_NDK I
set from my toolchain file). Output from CMake is at the bottom of
this email. The repository I'm configuring is here:

https://github.com/Orphis/boost-cmake

Logs:


$ cmake .. -GNinja
-DCMAKE_TOOLCHAIN_FILE="E:\code\_external\\android_armeabi-v7a.toolchain.cmake"
    -DCMAKE_BUILD_TYPE=Release     -DCMAKE_INSTALL_PREFIX=_install
-DBOOST_LOCALE_ENABLE_ICU_BACKEND=OFF
-DBOOST_LOCALE_ENABLE_ICONV_BACKEND=OFF
-- Android: Targeting API '15' with architecture 'arm', ABI
'armeabi-v7a', and processor 'armv7-a'
-- Android: Selected Clang toolchain 'arm-linux-androideabi-clang'
with GCC toolchain 'arm-linux-androideabi-4.9'
-- The C compiler identification is Clang 5.0.300080
-- The CXX compiler identification is Clang 5.0.300080
-- Check for working C compiler:
E:/android/ndk_72/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe
-- Check for working C compiler:
E:/android/ndk_72/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe
-- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler:
E:/android/ndk_72/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++.exe
-- Check for working CXX compiler:
E:/android/ndk_72/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++.exe
-- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Boost found: 1.63.0 E:/code/_external/boost-cmake/boost/boost_1_63_0
-- Boost found: 1.63.0 E:/code/_external/boost-cmake/boost/boost_1_63_0
-- Standalone mode detected
-- Looking for __linux__
-- Looking for __linux__ - found
-- Looking for _WIN32
-- Looking for _WIN32 - not found
-- Looking for __APPLE__
-- Looking for __APPLE__ - not found
-- Looking for __ANDROID__
-- Looking for __ANDROID__ - found
-- Looking for __FreeBSD__
-- Looking for __FreeBSD__ - not found
-- The ASM compiler identification is unknown
-- Found assembler:
E:/android/ndk/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe
CMake Error at libs/context.cmake:34 (enable_language):
  The CMAKE_ASM_COMPILER:

    E:/android/ndk/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe

  is not a full path to an existing compiler tool.

  Tell CMake where to find the compiler by setting either the environment
  variable "ASM" or the CMake cache entry CMAKE_ASM_COMPILER to the full path
  to the compiler, or to the compiler name if it is in the PATH.
Call Stack (most recent call first):
  CMakeLists.txt:63 (include)


-- Warning: Did not find file Compiler/-ASM

From rcdailey.lists at gmail.com  Fri Jun 23 15:19:40 2017
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Fri, 23 Jun 2017 14:19:40 -0500
Subject: [cmake-developers] Bug with CMAKE_ASM_COMPILER and Android NDK
In-Reply-To: <CAHd499CKYZ=97MJJRd3oOyjQLvCWSrUR2Ssa=wcWLizisBQdzQ@mail.gmail.com>
References: <CAHd499CKYZ=97MJJRd3oOyjQLvCWSrUR2Ssa=wcWLizisBQdzQ@mail.gmail.com>
Message-ID: <CAHd499AQ0ivgfD+8B0GOzLCoYGXVG1FeCefhq4+NeHUXj5jhQQ@mail.gmail.com>

Oh I'm using CMake 3.9.0 RC3

On Fri, Jun 23, 2017 at 2:18 PM, Robert Dailey <rcdailey.lists at gmail.com> wrote:
> So I have two environment variables:
>
> ANDROID_NDK = E:\android\ndk
> ANDROID_NDK_72 = E:\android\ndk_72
>
> In my toolchain file, I do this:
>
>
>
> set( CMAKE_SYSTEM_NAME Android )
> set( CMAKE_SYSTEM_VERSION 15 ) # API level
> set( CMAKE_ANDROID_ARCH_ABI armeabi-v7a )
> set( CMAKE_ANDROID_STL_TYPE c++_shared )
> set( CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION clang )
>
> # ANDROID_NDK_72 represents a separate path to the NDK for 7.2 frontend
> # builds and later. This is to make it less painful to convert between
> # Crystax (7.1.x) and official NDK, which was restored in version 7.2.
> string(REGEX REPLACE "\\\\" "/" ndk_path "$ENV{ANDROID_NDK_72}")
> if( NOT EXISTS ${ndk_path} )
>     string(REGEX REPLACE "\\\\" "/" ndk_path "$ENV{ANDROID_NDK}")
> endif()
>
> set( CMAKE_ANDROID_NDK ${ndk_path} )
> unset(ndk_path)
>
>
>
> This works fine, until you do something like this in your CMake scripts:
>
>
> enable_language(ASM)
>
>
> CMake appears to find clang.exe in the wrong place (It's using
> ANDROID_NDK directly somehow instead of using the CMAKE_ANDROID_NDK I
> set from my toolchain file). Output from CMake is at the bottom of
> this email. The repository I'm configuring is here:
>
> https://github.com/Orphis/boost-cmake
>
> Logs:
>
>
> $ cmake .. -GNinja
> -DCMAKE_TOOLCHAIN_FILE="E:\code\_external\\android_armeabi-v7a.toolchain.cmake"
>     -DCMAKE_BUILD_TYPE=Release     -DCMAKE_INSTALL_PREFIX=_install
> -DBOOST_LOCALE_ENABLE_ICU_BACKEND=OFF
> -DBOOST_LOCALE_ENABLE_ICONV_BACKEND=OFF
> -- Android: Targeting API '15' with architecture 'arm', ABI
> 'armeabi-v7a', and processor 'armv7-a'
> -- Android: Selected Clang toolchain 'arm-linux-androideabi-clang'
> with GCC toolchain 'arm-linux-androideabi-4.9'
> -- The C compiler identification is Clang 5.0.300080
> -- The CXX compiler identification is Clang 5.0.300080
> -- Check for working C compiler:
> E:/android/ndk_72/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe
> -- Check for working C compiler:
> E:/android/ndk_72/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe
> -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Check for working CXX compiler:
> E:/android/ndk_72/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++.exe
> -- Check for working CXX compiler:
> E:/android/ndk_72/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++.exe
> -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Boost found: 1.63.0 E:/code/_external/boost-cmake/boost/boost_1_63_0
> -- Boost found: 1.63.0 E:/code/_external/boost-cmake/boost/boost_1_63_0
> -- Standalone mode detected
> -- Looking for __linux__
> -- Looking for __linux__ - found
> -- Looking for _WIN32
> -- Looking for _WIN32 - not found
> -- Looking for __APPLE__
> -- Looking for __APPLE__ - not found
> -- Looking for __ANDROID__
> -- Looking for __ANDROID__ - found
> -- Looking for __FreeBSD__
> -- Looking for __FreeBSD__ - not found
> -- The ASM compiler identification is unknown
> -- Found assembler:
> E:/android/ndk/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe
> CMake Error at libs/context.cmake:34 (enable_language):
>   The CMAKE_ASM_COMPILER:
>
>     E:/android/ndk/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe
>
>   is not a full path to an existing compiler tool.
>
>   Tell CMake where to find the compiler by setting either the environment
>   variable "ASM" or the CMake cache entry CMAKE_ASM_COMPILER to the full path
>   to the compiler, or to the compiler name if it is in the PATH.
> Call Stack (most recent call first):
>   CMakeLists.txt:63 (include)
>
>
> -- Warning: Did not find file Compiler/-ASM

From michael.scott250 at gmail.com  Sun Jun 25 05:34:22 2017
From: michael.scott250 at gmail.com (Michael Scott)
Date: Sun, 25 Jun 2017 12:34:22 +0300
Subject: [cmake-developers] Contributing to CMake Server
Message-ID: <405327f9-1821-bfa7-1411-68cbc10dd9ea@gmail.com>

Hi,

I'm looking to do a bit more CMake development and the CMake server 
project looks interesting. Does this area still need more contributors 
and what's the best way to see what tasks there are?

Thanks,
Michael

From csiga.biga at aol.com  Sun Jun 25 12:19:42 2017
From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=)
Date: Sun, 25 Jun 2017 18:19:42 +0200
Subject: [cmake-developers] CMake PCH Prototype
In-Reply-To: <CANZMcXoXrb_faWmiNtvfcOEKL0yKeXBfFtqaQW9JyEg9k2tu2g@mail.gmail.com>
References: <CANZMcXoXrb_faWmiNtvfcOEKL0yKeXBfFtqaQW9JyEg9k2tu2g@mail.gmail.com>
Message-ID: <mailman.6.1498407582.15417.cmake-developers@cmake.org>

I just wanted to note that big thumbs up for both the effort and the design. Eagerly awaiting the time I can use it in my projects. As soon as it lands, I?ll imbue the triSYCL CMake scripts to make use of it.

Sidenote/question: Is it possible for multiple targets to share the same PCH? This usage scenario was not apparent to me based on the discussions. triSYCL has 100+ single source file targets but all rely on roughly the same set of STL and Boost dependencies that never change throughout development.

Felad?: Daniel Pfeifer
Elk?ldve: 2017. j?nius 18., vas?rnap 17:34
C?mzett: Julian Landesberger; CMake Developers
T?rgy: [cmake-developers] CMake PCH Prototype

Hi Julian,

I have rebased my old precompiled-headers branch on master and created a work-in-progress merge-request here:?https://gitlab.kitware.com/cmake/cmake/merge_requests/984

Cheers, Daniel


2017-06-15 13:38 GMT+02:00 Julian Landesberger <j.landesberger at gmail.com>:
Hallo Daniel,
wir hatten uns nach deinem Meetup-Vortrag letzte Woche kurz ?ber die Verwaltung von precompiled headers in CMake unterhalten. Du meintest damals, du h?ttest bereits eine Art Prototyp daf?r geschrieben, der aber noch nicht an "gro?en" Projekten getestet wurde, und, dass du ihn daf?r zur Verf?gung stellen k?nntest.
Ich w?rde den Prototypen gerne am Simulationscode des Lehrstuhls f?r Computation in Engineering der TU M?nchen ausprobieren. Der hat immerhin ?ber 6000 source- und header-Dateien, ist also kein kompaktes Beispielprojekt mehr.
W?rde mich freuen wenn wir da was machen k?nnten und beste Gr??e!
Julian Landesberger


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170625/384a17a5/attachment.html>

From brad.king at kitware.com  Mon Jun 26 10:05:19 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 26 Jun 2017 10:05:19 -0400
Subject: [cmake-developers] Contributing to CMake Server
In-Reply-To: <405327f9-1821-bfa7-1411-68cbc10dd9ea@gmail.com>
References: <405327f9-1821-bfa7-1411-68cbc10dd9ea@gmail.com>
Message-ID: <22ae93e2-7bfb-e4c3-c851-201b9533aef4@kitware.com>

On 06/25/2017 05:34 AM, Michael Scott wrote:
> I'm looking to do a bit more CMake development and the CMake server 
> project looks interesting. Does this area still need more contributors 
> and what's the best way to see what tasks there are?

Thanks for volunteering.  There are some open issue tracker entries
with the `area:cmake-server` label.  There are also some merge requests
that you could look at reviewing.

Otherwise, development is primarily driven by the needs of IDE clients.
If you get involved with any of those it may provide more guidance.

Thanks,
-Brad


From brad.king at kitware.com  Mon Jun 26 11:25:20 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 26 Jun 2017 11:25:20 -0400
Subject: [cmake-developers] Bug with CMAKE_ASM_COMPILER and Android NDK
In-Reply-To: <CAHd499CKYZ=97MJJRd3oOyjQLvCWSrUR2Ssa=wcWLizisBQdzQ@mail.gmail.com>
References: <CAHd499CKYZ=97MJJRd3oOyjQLvCWSrUR2Ssa=wcWLizisBQdzQ@mail.gmail.com>
Message-ID: <4e589115-a70c-7bae-4646-c6910f919cab@kitware.com>

On 06/23/2017 03:18 PM, Robert Dailey wrote:
> enable_language(ASM)
> 
> CMake appears to find clang.exe in the wrong place

Add a `Modules/Platform/Android-Determine-ASM.cmake` module
based on `Modules/Platform/Android-Determine-CXX.cmake`.

Also the modules

  Modules/Platform/Android/Determine-Compiler-NDK.cmake
  Modules/Platform/Android/Determine-Compiler-Standalone.cmake
  Modules/Platform/Android/Determine-Compiler.cmake

need to be updated to set `_ANDROID_TOOL_ASM_COMPILER` and similar
variables for ASM as is done for C and CXX.

-Brad


From rcdailey.lists at gmail.com  Mon Jun 26 11:58:38 2017
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Mon, 26 Jun 2017 10:58:38 -0500
Subject: [cmake-developers] 3.9.0-rc3: CMAKE_ANDROID_NDK_DEPRECATED_HEADERS
 doesn't work outside of toolchain
Message-ID: <CAHd499C3VT8-qnJUBokKPzPV0c0-PhKpDkPv+=iaz=UUkfm8iQ@mail.gmail.com>

Hi,

I tried setting CMAKE_ANDROID_NDK_DEPRECATED_HEADERS in a common CMake
script of mine (set during configuration but before any targets are
created). I also tried making it a cache variable, but in each case it
isn't working. I set like this:

set( CMAKE_ANDROID_NDK_DEPRECATED_HEADERS 1 )

And for r14b NDK, the unified headers were used, I expected them to
NOT be used. When I move the above line of code to my toolchain file,
it works as expected (the unified headers are NOT used).

Why does this only work in the toolchain file? I'd like to be able to
set it outside the toolchain file because I do quite a bit of logic to
determine if I want deprecated headers to be used or not; it's not
meant to be something specified by the user/toolchain in my case, but
rather something calculated.

Thanks in advance.

From rcdailey.lists at gmail.com  Mon Jun 26 15:06:19 2017
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Mon, 26 Jun 2017 14:06:19 -0500
Subject: [cmake-developers] Bug with CMAKE_ASM_COMPILER and Android NDK
In-Reply-To: <4e589115-a70c-7bae-4646-c6910f919cab@kitware.com>
References: <CAHd499CKYZ=97MJJRd3oOyjQLvCWSrUR2Ssa=wcWLizisBQdzQ@mail.gmail.com>
 <4e589115-a70c-7bae-4646-c6910f919cab@kitware.com>
Message-ID: <CAHd499D4x0zoma398wzNprdqh8O+8MXGfwQ5mL6dtaoGWzV0xQ@mail.gmail.com>

On Mon, Jun 26, 2017 at 10:25 AM, Brad King <brad.king at kitware.com> wrote:
> On 06/23/2017 03:18 PM, Robert Dailey wrote:
>> enable_language(ASM)
>>
>> CMake appears to find clang.exe in the wrong place
>
> Add a `Modules/Platform/Android-Determine-ASM.cmake` module
> based on `Modules/Platform/Android-Determine-CXX.cmake`.
>
> Also the modules
>
>   Modules/Platform/Android/Determine-Compiler-NDK.cmake
>   Modules/Platform/Android/Determine-Compiler-Standalone.cmake
>   Modules/Platform/Android/Determine-Compiler.cmake
>
> need to be updated to set `_ANDROID_TOOL_ASM_COMPILER` and similar
> variables for ASM as is done for C and CXX.

Are you saying I should modify my local installation? Or are these
your personal notes so that these changes get adopted upstream? Not
sure I understand...

From brad.king at kitware.com  Mon Jun 26 16:32:50 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 26 Jun 2017 16:32:50 -0400
Subject: [cmake-developers] 3.9.0-rc3:
 CMAKE_ANDROID_NDK_DEPRECATED_HEADERS doesn't work outside of toolchain
In-Reply-To: <CAHd499C3VT8-qnJUBokKPzPV0c0-PhKpDkPv+=iaz=UUkfm8iQ@mail.gmail.com>
References: <CAHd499C3VT8-qnJUBokKPzPV0c0-PhKpDkPv+=iaz=UUkfm8iQ@mail.gmail.com>
Message-ID: <6d16a99f-1850-a432-b6d4-3a87e7a4056f@kitware.com>

On 06/26/2017 11:58 AM, Robert Dailey wrote:
> Why does this only work in the toolchain file?

1. It needs to be set early.

2. It needs to propagate into try_compile projects.

The toolchain file is sufficient for both.  A cache entry is okay
for (1) but for (2) one would additionally need to set this:

  https://cmake.org/cmake/help/v3.9/variable/CMAKE_TRY_COMPILE_PLATFORM_VARIABLES.html

...though that is really meant for toolchain files too.

Note that toolchain files are meant to be local to the machine, not
distributed with source trees and full of introspection logic.  The
(local) author of the toolchain file should know the NDK version and
choose whether to use `CMAKE_ANDROID_NDK_DEPRECATED_HEADERS`.

Your project code could check the NDK version and error out if
the `CMAKE_ANDROID_NDK_DEPRECATED_HEADERS` is not correct.

-Brad


From brad.king at kitware.com  Mon Jun 26 16:34:19 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 26 Jun 2017 16:34:19 -0400
Subject: [cmake-developers] Bug with CMAKE_ASM_COMPILER and Android NDK
In-Reply-To: <CAHd499D4x0zoma398wzNprdqh8O+8MXGfwQ5mL6dtaoGWzV0xQ@mail.gmail.com>
References: <CAHd499CKYZ=97MJJRd3oOyjQLvCWSrUR2Ssa=wcWLizisBQdzQ@mail.gmail.com>
 <4e589115-a70c-7bae-4646-c6910f919cab@kitware.com>
 <CAHd499D4x0zoma398wzNprdqh8O+8MXGfwQ5mL6dtaoGWzV0xQ@mail.gmail.com>
Message-ID: <636bb13a-ed33-187f-5bfe-cb8311b40570@kitware.com>

On 06/26/2017 03:06 PM, Robert Dailey wrote:
> Are you saying I should modify my local installation? Or are these
> your personal notes so that these changes get adopted upstream?

These are notes for anyone that wants to fix this in CMake by doing
development.  I don't know if I'll find time myself.

-Brad


From maikelvandenhurk at hotmail.com  Tue Jun 27 10:34:37 2017
From: maikelvandenhurk at hotmail.com (maikel van den Hurk)
Date: Tue, 27 Jun 2017 14:34:37 +0000
Subject: [cmake-developers] Create target with dependency to all targets
 similar to 'cmake_check_build_system'
Message-ID: <DB6P195MB00382F6E233925124E7F48C6DADC0@DB6P195MB0038.EURP195.PROD.OUTLOOK.COM>

I am wondering why there is no entry to create a target which is a dependency for each target like the `cmake_check_build_system`. It feels bit hacky to overload add_dependencies() to achieve this or am I overlooking something.

Would something like this be good to add? If yes I could have a look into adding this, any pointers would be appreciated.


Thanks,

Maikel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170627/6b634f10/attachment.html>

From rcdailey.lists at gmail.com  Tue Jun 27 11:14:43 2017
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Tue, 27 Jun 2017 10:14:43 -0500
Subject: [cmake-developers] 3.9.0-rc3:
 CMAKE_ANDROID_NDK_DEPRECATED_HEADERS doesn't work outside of toolchain
In-Reply-To: <6d16a99f-1850-a432-b6d4-3a87e7a4056f@kitware.com>
References: <CAHd499C3VT8-qnJUBokKPzPV0c0-PhKpDkPv+=iaz=UUkfm8iQ@mail.gmail.com>
 <6d16a99f-1850-a432-b6d4-3a87e7a4056f@kitware.com>
Message-ID: <CAHd499DEytXjzJhB91v8iKWCSi_Qr0Himcd-8Du2FszgkEQgjw@mail.gmail.com>

On Mon, Jun 26, 2017 at 3:32 PM, Brad King <brad.king at kitware.com> wrote:
> On 06/26/2017 11:58 AM, Robert Dailey wrote:
>> Why does this only work in the toolchain file?
>
> 1. It needs to be set early.
>
> 2. It needs to propagate into try_compile projects.
>
> The toolchain file is sufficient for both.  A cache entry is okay
> for (1) but for (2) one would additionally need to set this:
>
>   https://cmake.org/cmake/help/v3.9/variable/CMAKE_TRY_COMPILE_PLATFORM_VARIABLES.html
>
> ...though that is really meant for toolchain files too.
>
> Note that toolchain files are meant to be local to the machine, not
> distributed with source trees and full of introspection logic.  The
> (local) author of the toolchain file should know the NDK version and
> choose whether to use `CMAKE_ANDROID_NDK_DEPRECATED_HEADERS`.
>
> Your project code could check the NDK version and error out if
> the `CMAKE_ANDROID_NDK_DEPRECATED_HEADERS` is not correct.

Your idea of erroring out seems like the best alternative solution,
although again I strongly feel this is something that should be
automated. It makes the user's life easier. If we know it only works a
certain way and have the necessary information to make that decision
programmatically, then why not? Software is supposed to make our lives
easier. Adding unnecessary manual steps doesn't really serve any
benefit IMHO.

Also at $DAYJOB, we all work on the same code base. Our product is
tested and verified to work on a distinct set of configurations. Why
would I ask each user to create their own toolchain file? Each time a
change is needed, I'd have to email the whole team and ask them to
make a specific change to their toolchain file. This is very
unproductive. I can't say I agree with your philosophy.

From brad.king at kitware.com  Tue Jun 27 11:22:36 2017
From: brad.king at kitware.com (Brad King)
Date: Tue, 27 Jun 2017 11:22:36 -0400
Subject: [cmake-developers] 3.9.0-rc3:
 CMAKE_ANDROID_NDK_DEPRECATED_HEADERS doesn't work outside of toolchain
In-Reply-To: <CAHd499DEytXjzJhB91v8iKWCSi_Qr0Himcd-8Du2FszgkEQgjw@mail.gmail.com>
References: <CAHd499C3VT8-qnJUBokKPzPV0c0-PhKpDkPv+=iaz=UUkfm8iQ@mail.gmail.com>
 <6d16a99f-1850-a432-b6d4-3a87e7a4056f@kitware.com>
 <CAHd499DEytXjzJhB91v8iKWCSi_Qr0Himcd-8Du2FszgkEQgjw@mail.gmail.com>
Message-ID: <b783d16f-0bf0-29d3-0a23-f343f96bde86@kitware.com>

On 06/27/2017 11:14 AM, Robert Dailey wrote:
> Also at $DAYJOB, we all work on the same code base. Our product is
> tested and verified to work on a distinct set of configurations. Why
> would I ask each user to create their own toolchain file?

If you have a toolchain file that works in some finite set of
tested environments then there is no reason not to share it
among them.

Why can't the logic to choose `CMAKE_ANDROID_NDK_DEPRECATED_HEADERS`
be in your toolchain file?  All it needs to know is the NDK location.

-Brad


From rcdailey.lists at gmail.com  Tue Jun 27 11:36:05 2017
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Tue, 27 Jun 2017 10:36:05 -0500
Subject: [cmake-developers] 3.9.0-rc3:
 CMAKE_ANDROID_NDK_DEPRECATED_HEADERS doesn't work outside of toolchain
In-Reply-To: <b783d16f-0bf0-29d3-0a23-f343f96bde86@kitware.com>
References: <CAHd499C3VT8-qnJUBokKPzPV0c0-PhKpDkPv+=iaz=UUkfm8iQ@mail.gmail.com>
 <6d16a99f-1850-a432-b6d4-3a87e7a4056f@kitware.com>
 <CAHd499DEytXjzJhB91v8iKWCSi_Qr0Himcd-8Du2FszgkEQgjw@mail.gmail.com>
 <b783d16f-0bf0-29d3-0a23-f343f96bde86@kitware.com>
Message-ID: <CAHd499BRCx0WHrW1=pkehyYON+BWncBxbfDHEU0f0j2XjeQ-7Q@mail.gmail.com>

On Tue, Jun 27, 2017 at 10:22 AM, Brad King <brad.king at kitware.com> wrote:
> On 06/27/2017 11:14 AM, Robert Dailey wrote:
>> Also at $DAYJOB, we all work on the same code base. Our product is
>> tested and verified to work on a distinct set of configurations. Why
>> would I ask each user to create their own toolchain file?
>
> If you have a toolchain file that works in some finite set of
> tested environments then there is no reason not to share it
> among them.
>
> Why can't the logic to choose `CMAKE_ANDROID_NDK_DEPRECATED_HEADERS`
> be in your toolchain file?  All it needs to know is the NDK location.

Ok maybe I'm misunderstanding the design intent for toolchain files. I
agree they shouldn't do much introspection (i.e. "business logic"),
but I've always made sure to provide multiple toolchain files if
necessary in version control, one per supported (tested) configuration
for the code base. Generally speaking, I provide one per supported
platform (Android, Windows, Linux, etc). However, I will not specify
things in the toolchain file that are not "static". Basically, some
things I like to determine programmatically. Putting in them in the
toolchain file violates the "introspection" rule, but also results in
code duplication since I have to do that same introspection in each
toolchain file.

So my specific case is this: Unified headers have been supported since
NDK r14. However, because of certain libraries and language features
that we use, our code fails to compile due to bugs in the unified
headers. Again for our specific code base, these bugs are addressed in
NDK r15b. So now I'm faced with a situation: Just because unified
headers are present doesn't mean we should use them. So I can no
longer base the decision to use unified headers on when they were
introduced, but it needs to be based on an arbitrary NDK version.

To solve this issue, I have come up with this logic:
https://gist.github.com/rcdailey/0ee52bfca634e7da55b6f86b9af91911

This CMake logic allows me to obtain the version of the NDK the user
has on their system and based on that version I can strategically set
the CMAKE_ANDROID_NDK_DEPRECATED_HEADERS variable. This is all
transparent to users on my team. None of them have done the research I
have into this, so they would not know which NDK to use or when to set
this flag to 1 or 0. We support r14 and r15 in different environments.

Maybe my situation is the exception to the rule, but I just don't see
an elegant way to do what I want.

From brad.king at kitware.com  Tue Jun 27 12:07:05 2017
From: brad.king at kitware.com (Brad King)
Date: Tue, 27 Jun 2017 12:07:05 -0400
Subject: [cmake-developers] 3.9.0-rc3:
 CMAKE_ANDROID_NDK_DEPRECATED_HEADERS doesn't work outside of toolchain
In-Reply-To: <CAHd499BRCx0WHrW1=pkehyYON+BWncBxbfDHEU0f0j2XjeQ-7Q@mail.gmail.com>
References: <CAHd499C3VT8-qnJUBokKPzPV0c0-PhKpDkPv+=iaz=UUkfm8iQ@mail.gmail.com>
 <6d16a99f-1850-a432-b6d4-3a87e7a4056f@kitware.com>
 <CAHd499DEytXjzJhB91v8iKWCSi_Qr0Himcd-8Du2FszgkEQgjw@mail.gmail.com>
 <b783d16f-0bf0-29d3-0a23-f343f96bde86@kitware.com>
 <CAHd499BRCx0WHrW1=pkehyYON+BWncBxbfDHEU0f0j2XjeQ-7Q@mail.gmail.com>
Message-ID: <4fe38c6e-6d78-ab03-97bb-f1773bdcf76b@kitware.com>

On 06/27/2017 11:36 AM, Robert Dailey wrote:
> Ok maybe I'm misunderstanding the design intent for toolchain files. 

Originally they were intended to contain information local to the
machine, like `set(CMAKE_ANDROID_NDK /path/on/my/machine/to/ndk)`.
In controlled environments that share many things it makes sense
to have deployable toolchain files instead.

> Basically, some things I like to determine programmatically. Putting
> in them in the toolchain file violates the "introspection" rule, but
> also results in code duplication

Toolchain files can `include()` other files from next to them.  That
can be used to avoid duplicate code.

The only information you need within your toolchain file logic to
compute CMAKE_ANDROID_NDK_DEPRECATED_HEADERS is CMAKE_ANDROID_NDK.
If you add logic to find/require CMAKE_ANDROID_NDK up front then you
can check its version.

CMake's `Modules/Platform/Android-Determine.cmake` file has very little
logic to choose `CMAKE_ANDROID_NDK` if it is not set by the user.  You
can either duplicate this in a toolchain file helper or take advantage
of knowledge about your controlled environments to have a shorter version.

-Brad


From robert.maynard at kitware.com  Tue Jun 27 14:05:08 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 27 Jun 2017 14:05:08 -0400
Subject: [cmake-developers] [ANNOUNCE] CMake 3.9.0-rc5 is ready for testing
Message-ID: <CAFzjYVpaCJ7CUGaqpra_Rq53+Oj+J1EED4UE8ygEozguPh5BYg@mail.gmail.com>

I am proud to announce the fifth CMake 3.9 release candidate.
  https://cmake.org/download/

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

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

Some of the more significant changes in CMake 3.9 are:

* "CUDA" is now supported by the Visual Studio Generators for VS
  2010 and above.  This complements the existing support by the
  Makefile Generators and the "Ninja" generator. CUDA 8.0.61 or higher
  is recommended due to known bugs in the VS integration by earlier
  versions.

* CMake is now aware of the "C++ standards" and "C standards" and
  their associated meta-features for the following "compiler ids":
  "Cray", "PGI", and "XL".

* The "add_library()" command "IMPORTED" option learned to support
  Object Libraries.

* All "find_" commands now have a "PACKAGE_ROOT" search path group
  that is first in the search heuristics.  If a "find_" command is
  called from inside a find module, then the CMake variable and
  environment variable named "<PackageName>_ROOT" are used as prefixes
  and are the first set of paths to be searched.

* The "install(TARGETS)" command learned a new "OBJECTS" option to
  specify where to install Object Libraries.

* The "install(EXPORT)" command learned how to export Object
  Libraries.

* A "BUILD_WITH_INSTALL_NAME_DIR" target property and corresponding
  "CMAKE_BUILD_WITH_INSTALL_NAME_DIR" variable were added to control
  whether to use the "INSTALL_NAME_DIR" target property value for
  binaries in the build tree.  This is for macOS "install_name" as
  "BUILD_WITH_INSTALL_RPATH" is for "RPATH".

* A "CUDA_PTX_COMPILATION" target property was added to Object
  Libraries to support compiling to ".ptx" files instead of host
  object files.

* A new "GoogleTest" module was added to provide the
  "gtest_add_tests()" function independently of the "FindGTest"
  module. The function was also updated to support keyword arguments,
  with functionality expanded to allow a test name prefix and suffix
  to be specified, the dependency on the source files to be optional
  and the list of discovered test cases to be returned to the caller.

* The "Ninja" generator has loosened the dependencies of object
  compilation.  Object compilation now depends only on custom targets
  and custom commands associated with libraries on which the object's
  target depends and no longer depends on the libraries themselves.
  Source files in dependent targets may now compile without waiting
  for their targets' dependencies to link.

* Interprocedural optimization (IPO) is now supported for GNU and
  Clang compilers using link time optimization (LTO) flags.  See the
  "INTERPROCEDURAL_OPTIMIZATION" target property and
  "CheckIPOSupported" module.

* The "TARGET_OBJECTS" "generator expression" is now supported by
  the "add_custom_command()" and "file(GENERATE)" commands.

CMake 3.9 Release Notes
***********************

Changes made since CMake 3.8 include the following.


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


Languages
---------

* "CUDA" is now supported by the Visual Studio Generators for VS
  2010 and above.  This complements the existing support by the
  Makefile Generators and the "Ninja" generator. CUDA 8.0.61 or higher
  is recommended due to known bugs in the VS integration by earlier
  versions.

* CMake is now aware of the "C++ standards" and "C standards" and
  their associated meta-features for the following "compiler ids":
  "Cray", "PGI", and "XL".


Generators
----------

* Visual Studio Generators for VS 2010 and above learned to support
  the "ASM_NASM" language when "nasm" is installed.

* The "Xcode" generator learned to create Xcode schema files. This
  is an experimental feature and can be activated by setting the
  "CMAKE_XCODE_GENERATE_SCHEME" variable to a "TRUE" value.


Commands
--------

* The "add_library()" command "IMPORTED" option learned to support
  Object Libraries.

* All "find_" commands now have a "PACKAGE_ROOT" search path group
  that is first in the search heuristics.  If a "find_" command is
  called from inside a find module, then the CMake variable and
  environment variable named "<PackageName>_ROOT" are used as prefixes
  and are the first set of paths to be searched.

* The "find_library()" command learned to search "libx32" paths when
  the build targets the "x32" ABI.  See the
  "FIND_LIBRARY_USE_LIBX32_PATHS" global property.

* The "include_external_msproject()" command learned to use the
  "MAP_IMPORTED_CONFIG_<CONFIG>" target property to map current
  configurations to the external configurations.

* The "install(TARGETS)" command learned a new "OBJECTS" option to
  specify where to install Object Libraries.

* The "install(EXPORT)" command learned how to export Object
  Libraries.

* The "project()" command learned an optional "DESCRIPTION"
  parameter to set the "PROJECT_DESCRIPTION" variable.

* The "separate_arguments()" command gained a "NATIVE_COMMAND" mode
  that performs argument separation depending on the host operating
  system.


Variables
---------

* A "CMAKE_ANDROID_NDK_DEPRECATED_HEADERS" variable was added for
  use when Cross Compiling for Android with the NDK to request use of
  the deprecated headers even when unified headers are available. The
  default is now to use unified headers if available.

* A "CMAKE_AUTOMOC_DEPEND_FILTERS" variable was introduced to allow
  "CMAKE_AUTOMOC" to extract additional dependency file names for
  "moc" from the contents of source files.

* A "CMAKE_AUTOUIC_SEARCH_PATHS" variable was introduced to allow
  "CMAKE_AUTOUIC" to search for "foo.ui" in more places than the
  vicinity of the file including "ui_foo.h".

* A "CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX" variable was added to
  tell the "find_library()" command to search in a "lib<suffix>"
  directory before each "lib" directory that would normally be
  searched.

* A "CMAKE_INTERPROCEDURAL_OPTIMIZATION" variable was added to
  initialize the "INTERPROCEDURAL_OPTIMIZATION" property on all
  targets.

* A "CMAKE_<LANG>_COMPILER_AR" variable was added to hold the path
  to the GCC/Clang wrapper of "ar".

* A "CMAKE_<LANG>_COMPILER_RANLIB" variable was added to hold the
  path to the GCC/Clang wrapper of "ranlib".

* The "CMAKE_SYSROOT_COMPILE" and "CMAKE_SYSROOT_LINK" variables
  were added to use separate sysroots for compiling and linking.


Properties
----------

* A new "AUTOGEN_BUILD_DIR" target property was introduced to set a
  custom output directory for "AUTOMOC", "AUTOUIC", and "AUTORCC".

* A new "AUTOMOC_DEPEND_FILTERS" target property was introduced to
  allow "AUTOMOC" to extract additional dependency file names for
  "moc" from the contents of source files.

* A new "AUTOUIC_SEARCH_PATHS" target property was introduced to
  allow "AUTOUIC" to search for "foo.ui" in more places than the
  vicinity of the file including "ui_foo.h".

* Global properties "AUTOGEN_SOURCE_GROUP", "AUTOMOC_SOURCE_GROUP"
  and "AUTORCC_SOURCE_GROUP" were introduced to allow files generated
  by "AUTOMOC" or "AUTORCC" to be placed in a "source_group()".

* A "BUILD_WITH_INSTALL_NAME_DIR" target property and corresponding
  "CMAKE_BUILD_WITH_INSTALL_NAME_DIR" variable were added to control
  whether to use the "INSTALL_NAME_DIR" target property value for
  binaries in the build tree.  This is for macOS "install_name" as
  "BUILD_WITH_INSTALL_RPATH" is for "RPATH".

* A "CUDA_PTX_COMPILATION" target property was added to Object
  Libraries to support compiling to ".ptx" files instead of host
  object files.

* A "GENERATOR_IS_MULTI_CONFIG" global property was added to
  determine whether the current generator is a multi-configuration
  generator (such as Visual Studio Generators or "Xcode").

* The "INTERPROCEDURAL_OPTIMIZATION" target property is now enforced
  when enabled.  CMake will add IPO flags unconditionally or produce
  an error if it does not know the flags for the current compiler. The
  project is now responsible to use the "CheckIPOSupported" module to
  check for IPO support before enabling the target property.  See
  policy "CMP0069".

* The "WINDOWS_EXPORT_ALL_SYMBOLS" target property may now be used
  in combination with explicit ".def" files in order to export all
  symbols from the object files within a target plus an explicit list
  of symbols that the linker finds in dependencies (e.g.
  "msvcrt.lib").


Modules
-------

* A "CheckIPOSupported" module was added to help projects check
  whether interprocedural optimization (IPO) is supported by the
  current toolchain and CMake version.

* The "CMakeFindDependencyMacro" module "find_dependency" macro now
  forwards all arguments to the underlying "find_package()" call.
  Existing uses will continue to function as before, but callers can
  now access the full suite of arguments that "find_package" accepts.

* The "FeatureSummary" module "feature_summary()" command now
  accepts the new "DEFAULT_DESCRIPTION" option that will print the
  default title for the selected package type.

* The "FeatureSummary" module gained a new
  "FeatureSummary_<TYPE>_DESCRIPTION" variable that can be defined for
  each "<TYPE>" to replace the type name with the specified string
  whenever the package type is used in an output string by the module.

* The "FindDoxygen" module learned to control Doxygen behavior using
  CMake variables and generate documentation via the newly added
  "doxygen_add_docs()" function. The Doxygen input file ("Doxyfile")
  is automatically generated and doxygen is run as part of a custom
  target. Additional components can be specified to find optional
  tools: "dot", "mscgen" and "dia".

* The "FindMPI" module now provides imported targets.

* The "FindProtobuf" module "protobuf_generate_cpp()" command gained
  an "EXPORT_MACRO" option to specify the name of a DLL export markup
  macro.

* The "FindProtobuf" module now supports usage of static libraries
  for Unix via a new "Protobuf_USE_STATIC_LIBS" input variable.

* The "FindProtobuf" module now provides imported targets when the
  libraries are found.

* A new "GoogleTest" module was added to provide the
  "gtest_add_tests()" function independently of the "FindGTest"
  module. The function was also updated to support keyword arguments,
  with functionality expanded to allow a test name prefix and suffix
  to be specified, the dependency on the source files to be optional
  and the list of discovered test cases to be returned to the caller.


CTest
-----

* The "ctest_submit()" command gained a "HTTPHEADER" option to
  specify custom headers to send during submission.

* The "ctest(1)" executable gained new options which allow the
  developer to disable automatically adding tests to the test set to
  satisfy fixture dependencies. "-FS" prevents adding setup tests for
  fixtures matching the provided regular expression, "-FC" prevents
  adding cleanup tests for matching fixtures and "-FA" prevents adding
  any test for matching fixtures.

* A "DISABLED" test property was added to mark tests that are
  configured but explicitly disabled so they do not run.


CPack
-----

* The "CPackArchive" module learned to modify the filename per-
  component.  See the "CPACK_ARCHIVE_FILE_NAME" variable and its per-
  component version "CPACK_ARCHIVE_<component>_FILE_NAME".

* The "CPackComponent" module "cpack_add_component()" command gained
  a new "PLIST <filename>" option to specify the "pkgbuild" "--
  component-plist" argument when using the "productbuild" generator.

* The "CPackIFW" module "cpack_ifw_configure_component()" and
  "cpack_ifw_configure_component_group()" commands gained
  internationalization support for "DISPLAY_NAME" and "DESCRIPTION"
  options.

* The "CPackIFW" module learned the new hint "CPACK_IFW_ROOT"
  variable for finding the QtIFW tool suite installed in a non-
  standard place.

* The "CPackProductBuild" module gained a new
  "CPACK_PRODUCTBUILD_RESOURCES_DIR" variable to specify resources to
  be copied into the "Resources" directory.

* The "CPackRPM" module learned to modify the "debuginfo" package
  name.  See the "CPACK_RPM_DEBUGINFO_FILE_NAME" variable.

* The "CPackWIX" module patching system now has the ability to set
  additional attributes.  This can be done by specifying attributes
  with the "CPackWiXFragment" XML tag after the "Id" attribute. See
  the "CPACK_WIX_PATCH_FILE" variable.

* The CPack WIX generator implemented a new
  "CPACK_WIX_ROOT_FOLDER_ID" variable which allows using a custom root
  folder ID instead of the default "ProgramFilesFolder" /
  "ProgramFiles64Folder".


Other
-----

* Interprocedural optimization (IPO) is now supported for GNU and
  Clang compilers using link time optimization (LTO) flags.  See the
  "INTERPROCEDURAL_OPTIMIZATION" target property and
  "CheckIPOSupported" module.

* The "TARGET_OBJECTS" "generator expression" is now supported by
  the "add_custom_command()" and "file(GENERATE)" commands.

* Two new informational generator expressions to retrieve Apple
  Bundle directories have been added. The first one
  "$<TARGET_BUNDLE_DIR:tgt>" outputs the full path to the Bundle
  directory, the other one "$<TARGET_BUNDLE_CONTENT_DIR:tgt>" outputs
  the full path to the "Contents" directory of macOS Bundles and App
  Bundles. For all other bundle types and SDKs it is identical with
  "$<TARGET_BUNDLE_DIR:tgt>". The new expressions are helpful to query
  Bundle locations independent of the different Bundle types and
  layouts on macOS and iOS.


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

* An explicit deprecation diagnostic was added for policies
  "CMP0036" and below.  The "cmake-policies(7)" manual explains that
  the OLD behaviors of all policies are deprecated and that projects
  should always port to the NEW behaviors as soon as possible.

* The "Visual Studio 8 2005" generator is now deprecated and will be
  removed in a future version of CMake.

* The "Visual Studio 7 .NET 2003" generator has been removed.

* The "Xcode" generator dropped support for Xcode versions older
  than 3.

* The "FindDoxygen" module has deprecated several variables.

* The version of curl bundled with CMake no longer accepts URLs of
  the form "file://c:/..." on Windows due to a change in upstream curl
  7.52.  Use the form "file:///c:/..." instead to work on all
  versions.


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

* When using "AUTOMOC", CMake now scans for the presence of the
  "Q_PLUGIN_METADATA" macro and reruns moc when the file from the
  macro's "FILE" argument changes.

* When "AUTOMOC" detects an include statement of the form "#include
  "moc_<basename>.cpp"" the search for the respective header file now
  looks in the "INCLUDE_DIRECTORIES" of the target as well.

* When running tests, CTest learned to treat skipped tests (using
  the "SKIP_RETURN_CODE" property) the same as tests with the new
  "DISABLED" property. Due to this change, CTest will not indicate
  failure when all tests are either skipped or pass.

* The "Ninja" generator has loosened the dependencies of object
  compilation.  Object compilation now depends only on custom targets
  and custom commands associated with libraries on which the object's
  target depends and no longer depends on the libraries themselves.
  Source files in dependent targets may now compile without waiting
  for their targets' dependencies to link.

* On macOS, the default application bundle "Info.plist" file now
  enables Hi-DPI support.

* On macOS, "RPATH" settings such as "BUILD_WITH_INSTALL_RPATH" no
  longer affect the "install_name" field.  See policy "CMP0068".

----------------------------------------------------------------------------
Changes made since CMake 3.9.0-rc4:

Brad King (7):
  GCC,Clang: Mark CMAKE_<LANG>_COMPILER_{AR,RANLIB} as advanced
  GetPrerequisites: Do not warn about non-absolute UCRT system libraries
  Tests: Enable languages explicitly in RunCMake.target_compile_features
  target_compile_features: Do not crash on non-enabled language
  VS: Fix support for nvcc flags not in our flag table
  FindDoxygen: Add private prefix to internal variables
  CMake 3.9.0-rc5

From rcdailey.lists at gmail.com  Wed Jun 28 21:14:01 2017
From: rcdailey.lists at gmail.com (Robert Dailey)
Date: Wed, 28 Jun 2017 20:14:01 -0500
Subject: [cmake-developers] Built-in tag support for FindDoxygen
Message-ID: <CAHd499CUSKGVBHKV3HaWqDXqLN-SiNLV8d6kjvNOqsWhdSNezA@mail.gmail.com>

Doxygen supports linking external documentation together:
https://www.stack.nl/~dimitri/doxygen/manual/external.html

Using doxygen_add_docs(), it doesn't provide built-in support for tag
files. I'm thinking this would be beneficial since the way the
function is designed encourages modular documentation. At least, I
have my projects structured like this (targets):

A
A_doxygen
B
B_doxygen
C
C_doxygen

I have 1 doxygen target per real library target. And each library has
dependencies on others. When library C uses something from A, I want
C_doxygen to link to the tagfile generated by A_doxygen.

At the moment I'm accomplishing this by adding a target property to
each real target to keep track of target dependencies. Example:

add_library(C ...)
target_link_libraries(C A)
set_property(TARGET C PROPERTY TARGET_DEPENDENCIES A)

When I'm building A_doxygen target (using doxygen_add_docs()), I
specify DOXYGEN_GENERATE_TAGFILE. Then in C_doxygen, I specify
DOXYGEN_TAGFILES to point to the one output by A_doxygen.

I don't like keeping target properties to query the dependency tree,
but this is the best I could come up with. Is there value in
incorporating this into FindDoxygen.cmake? If so, I'd like to
contribute it, if it's useful.

Would love feedback and advice on this!

From claus.klein at arcormail.de  Thu Jun 29 16:09:52 2017
From: claus.klein at arcormail.de (Claus Klein)
Date: Thu, 29 Jun 2017 22:09:52 +0200
Subject: [cmake-developers] how does target_compile_features() test the
	c++11 conformance?
Message-ID: <87B7CF36-2DFF-4B1D-A7EA-4DDC526FE181@arcormail.de>

Hi,

I am using cmake V3.8.2 and VS 2013 and work with a c++11 library.

Wenn I use this, no error message is seen:

 target_compile_features(${targetname} PRIVATE cxx_std_11) # OK


But wenn I use this most features are missing:

target_compile_features(${targetname} PRIVATE
   cxx_contextual_conversions  # OK
   cxx_final   # OK
   cxx_override    # OK
   cxx_variadic_templates  # OK

   #FIXME: missing features at MS VS12 2013:

   cxx_aggregate_default_initializers
   cxx_attribute_deprecated
   cxx_binary_literals
   cxx_constexpr
   cxx_decltype_auto
   cxx_decltype_incomplete_return_types
   cxx_defaulted_move_initializers
   cxx_digit_separators
   cxx_generic_lambdas
   cxx_lambda_init_captures
   cxx_noexcept
   cxx_relaxed_constexpr
   cxx_return_type_deduction
   cxx_variable_templates
 )

with regards
Claus


From chuck.atkins at kitware.com  Thu Jun 29 16:39:17 2017
From: chuck.atkins at kitware.com (Chuck Atkins)
Date: Thu, 29 Jun 2017 16:39:17 -0400
Subject: [cmake-developers] how does target_compile_features() test the
 c++11 conformance?
In-Reply-To: <87B7CF36-2DFF-4B1D-A7EA-4DDC526FE181@arcormail.de>
References: <87B7CF36-2DFF-4B1D-A7EA-4DDC526FE181@arcormail.de>
Message-ID: <CAOXZzG6gqHPJqANaqwOLdcHt-yQkbVFoXA+oLaagjTsRVGYD3w@mail.gmail.com>

Hi Claus,

how does target_compile_features() test the c++11 conformance?
>

It doesn't.  The language features supported by different compilers and
thier various versions is basically a manually constructed whitelist since
testing for them at configure time is far too costly.  You can see the
details for msvc here in the internal compiler detection logic in the CMake
distribution: Modules/Compiler/MSVC-CXX-FeatureTests.cmake


 target_compile_features(${targetname} PRIVATE cxx_std_11) # OK
>
> But wenn I use this most features are missing:
>
> target_compile_features(${targetname} PRIVATE
>    cxx_contextual_conversions  # OK
> ...

   #FIXME: missing features at MS VS12 2013:
> ...
>    cxx_aggregate_default_initializers

...
>  )
>

The cxx_std_11 compile feature is a meta-feature.  Basically it tells CMake
to Use the compiler in C++11 mode if possible, and then the cmpiler will do
what it can.  This is effectively adding the -std=c++11 flag to gcc or
-std=c++1y for cxx_std_14.  The compiler may not support all the features
but CMake knows that it can at least support *some* so it will try to use
what it can.  MSVC is a bit of an oddball with compilers since you cant
actually control the language level (maybe with 2017 you can), i.e. you
can't explicitly instruct msvc to build in C++98 mode only.

The individual language features wre initially put in place due to the
half-broken C++11 implementations that thend to be available in many
compilers (as you're finding out).  However, over time as it's used more
that level of granularity is less and less useful.  Hence the addition of
the meta-features for language levels.  Several compilers that have
reecently added language standard support in CMake (IBM XL, Cray, PGI) are
now just using the meta-feature as the maintenace burdon for maintaining
the feature tables is too great with respect to the reward.

Hope that helps clarify the state of things.

----------
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170629/c70f5100/attachment.html>

From craig.scott at crascit.com  Fri Jun 30 22:48:27 2017
From: craig.scott at crascit.com (Craig Scott)
Date: Sat, 1 Jul 2017 12:48:27 +1000
Subject: [cmake-developers] Built-in tag support for FindDoxygen
In-Reply-To: <CAHd499CUSKGVBHKV3HaWqDXqLN-SiNLV8d6kjvNOqsWhdSNezA@mail.gmail.com>
References: <CAHd499CUSKGVBHKV3HaWqDXqLN-SiNLV8d6kjvNOqsWhdSNezA@mail.gmail.com>
Message-ID: <CA+dygYmm-rAcbckLj7uwcXW_=joTsBWy7mUUcA=MiYQ2OkrgAw@mail.gmail.com>

On Thu, Jun 29, 2017 at 11:14 AM, Robert Dailey <rcdailey.lists at gmail.com>
wrote:

> Doxygen supports linking external documentation together:
> https://www.stack.nl/~dimitri/doxygen/manual/external.html
>
> Using doxygen_add_docs(), it doesn't provide built-in support for tag
> files. I'm thinking this would be beneficial since the way the
> function is designed encourages modular documentation. At least, I
> have my projects structured like this (targets):
>
> A
> A_doxygen
> B
> B_doxygen
> C
> C_doxygen
>
> I have 1 doxygen target per real library target. And each library has
> dependencies on others. When library C uses something from A, I want
> C_doxygen to link to the tagfile generated by A_doxygen.
>
> At the moment I'm accomplishing this by adding a target property to
> each real target to keep track of target dependencies. Example:
>
> add_library(C ...)
> target_link_libraries(C A)
> set_property(TARGET C PROPERTY TARGET_DEPENDENCIES A)
>
> When I'm building A_doxygen target (using doxygen_add_docs()), I
> specify DOXYGEN_GENERATE_TAGFILE. Then in C_doxygen, I specify
> DOXYGEN_TAGFILES to point to the one output by A_doxygen.
>
> I don't like keeping target properties to query the dependency tree,
> but this is the best I could come up with. Is there value in
> incorporating this into FindDoxygen.cmake? If so, I'd like to
> contribute it, if it's useful.
>

I think there's good potential for this idea. The doxygen_add_docs()
function could record the value of the DOXYGEN_GENERATE_TAGFILE variable in
a target property (I'd recommend using the same name as the variable). A
new DEPENDS option could be added to doxygen_add_docs() which would specify
other targets this one depends on. This would invoke add_dependencies() to
fulfil build ordering as usual, but it could also inspect the target
properties of the dependees and if the DOXYGEN_GENERATE_TAGFILE property is
set, then the DOXYGEN_TAGFILES variable could be augmented to pick up that
tag file somehow. You'd have to be careful how the paths were handled to
ensure they worked robustly, but conceptually at least I think this might
be possible and useful. Example usage would then be something like this:

# Populate DOXYGEN_GENERATE_TAGFILE if not already set,
# use existing contents otherwise. Either way, define a target property
# on foo which records the value.
doxygen_add_docs(foo)

# Does a similar thing as above for this target, but also picks up the
# tag file from foo as recorded in its target properties and augments

# the DOXYGEN_TAGFILES variable as appropriate.

doxygen_add_docs(bar DEPENDS foo)


You would need to be careful with how to handle contents of
DOXYGEN_GENERATE_TAGFILE and DOXYGEN_TAGFILES that the project might
already set. As a conservative measure, you might want to consider adding
an option NO_AUTO_TAGFILES or similar to disable any of this logic in case
a project does something complex and doxygen_add_docs() needs to be told to
leave it completely up to the project to handle. The doxygen_add_docs()
function was originally added with the intention of making it as easy as
possible for projects to use Doxygen with minimal extra configuration, so I
think having the auto tag handling enabled by default would probably be the
right call, as long as there's a way for projects to disable it if needed.


-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170701/d108754b/attachment.html>