[Cmake-commits] (no subject)

[Budi]

How to set PIC flag in build by use of cmake command line?
as in gcc is the option -fPIC
e.g.
cmake -G "Unix Makefiles"   (.. ?)
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[CMake] Vulkan Headers error and XCB error too X11 error

[Dorian ROSSE]

hello,


I have those errors when I launch python update_deps.py depuis 
vulkan-basic-samples/scripts in attachment a print screen,

Under this print screen there is this line :

'CMakeLists.txt:94 (find_package)'

For the first error I am in add Vulkan Headers GitHub It looks like registry is 
in headers !

I have edit a lot of cmake files about thoses errors without repair thoses 
errors...

Thank you in advance to mailing list cmake to help myself run correctly this 
python script,

Regards.


Dorian ROSSE.


-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] [ANNOUNCE] CMake mailing list now closed

[Robert Bielik]

Bad timing...



Sent from my Xperia by Sony smartphone


 Robert Maynard via CMake wrote 

As was previously announced, CMake is stopping mailing list usage, and
has transitioned to a Discourse forum 
(https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdiscourse.cmake.orgdata=02%7C01%7Crobert.bielik%40dirac.com%7C7f05b503784c49d77bff08d7d667f36d%7C266f25c575d44d978f448d816a1f6a35%7C1%7C0%7C637213614279741835sdata=K1hQIT4E8HVKOUCRaeYKF3hMi%2BdOxUnQX4xBHfTkFPA%3Dreserved=0).

While new posts to the mailing list are disabled, all previous
discussion will be archived so that the knowledge can be searched
going forward.

Hopefully I will see you all on discourse.cmake.org!
--

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org%2Fservicesdata=02%7C01%7Crobert.bielik%40dirac.com%7C7f05b503784c49d77bff08d7d667f36d%7C266f25c575d44d978f448d816a1f6a35%7C1%7C0%7C637213614279751828sdata=pe0cqOoEKatGaKW7XWgpSRtTm7YS%2F7bGYp53CaFx56s%3Dreserved=0

Visit other Kitware open-source projects at 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kitware.com%2Fplatformsdata=02%7C01%7Crobert.bielik%40dirac.com%7C7f05b503784c49d77bff08d7d667f36d%7C266f25c575d44d978f448d816a1f6a35%7C1%7C0%7C637213614279751828sdata=j4J%2BuMiMVUIYHN2qS1AcCmJWQCWGMDr%2B7P%2B2umDrYrU%3Dreserved=0

Follow this link to subscribe/unsubscribe:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcmake.org%2Fmailman%2Flistinfo%2Fcmakedata=02%7C01%7Crobert.bielik%40dirac.com%7C7f05b503784c49d77bff08d7d667f36d%7C266f25c575d44d978f448d816a1f6a35%7C1%7C0%7C637213614279751828sdata=VcZxFJzp36gEobgr%2FMOzVy7kOsYuBOkEiGcOVniMZZ0%3Dreserved=0

This mailing list is deprecated in favor of 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdiscourse.cmake.orgdata=02%7C01%7Crobert.bielik%40dirac.com%7C7f05b503784c49d77bff08d7d667f36d%7C266f25c575d44d978f448d816a1f6a35%7C1%7C0%7C637213614279751828sdata=y2wwa2ejz%2BwyT0EV66InXLDIDqFDGWO4ZuY1%2BsCnjGY%3Dreserved=0
The information in this email (including any attachments) may contain 
confidential and/or proprietary material. Any review, retransmission or use of 
this information by persons or entities other than the intended, authorized 
recipient is prohibited. If you received this email in error, please notify the 
sender and delete the material. For information regarding how Dirac handles 
personal data, please visit https://www.dirac.com/privacy-policy.
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] [ANNOUNCE] CMake mailing list now closed

[Robert Maynard via CMake]

As was previously announced, CMake is stopping mailing list usage, and
has transitioned to a Discourse forum (https://discourse.cmake.org).

While new posts to the mailing list are disabled, all previous
discussion will be archived so that the knowledge can be searched
going forward.

Hopefully I will see you all on discourse.cmake.org!
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] Need suggestions for implementation of new feature in cmake.

[Carlo Wood]

On Fri, 27 Mar 2020 07:18:11 +0100
Hendrik Sattler  wrote:

> Hi Carlo,
> 
> The answer is already right in front of you: "a && b" executes b only
> if a returns positive (zero exit code). This is already done for the
> mkdir.
> 
> And to answer the other question: no, you cannot assume a POSIX shell
> in a Makefile.
> 
> HS

Hi Hendrik,

thank you for your reply :). I kinda overlooked that I have to admit.
I think my brain saw the '&&' as shell scripting and the question
was if that is portable, or that the generated Makefile on my system
made use of that because of the platform that I am using.

So, for clarity, I can use:

add_custom_command(
  ...
  COMMAND ${cmd} && ${CMAKE_COMMAND} -E touch ${stamp_file}
)

Where ${cmd} is the user defined command,
and that will work portably on all supported platforms?

How should I do this for GENERATOR_IS_MULTI_CONFIG?

Carlo Wood

PS I assume that '||' also works then. Namely I also need the
   stamp file to be created when it doesn't exist.

   So really I need in addition

   COMMAND test -e ${stamp_file} || ${CMAKE_COMMAND} -E touch ${stamp_file}

Is 'test -e' also portable?

-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] Need suggestions for implementation of new feature in cmake.

[Hendrik Sattler]

Hi Carlo,

The answer is already right in front of you: "a && b" executes b only if a 
returns positive (zero exit code). This is already done for the mkdir.

And to answer the other question: no, you cannot assume a POSIX shell in a 
Makefile.

HS


Am 27. März 2020 05:53:39 MEZ schrieb Carlo Wood :
>Hello!
>
>I'm writing a patch for cmake to address
>https://gitlab.kitware.com/cmake/cmake/issues/19703
>
>but I need a little help; I'm only familiar with
>GNU/Linux and single target generator Makefile.
>
>In terms of a Makefile, if one uses ExternalProject_Add_Step, see
>
>https://cmake.org/cmake/help/latest/module/ExternalProject.html#explicit-step-management
>
>then something like this is generated:
>
>/path/to/stamp_dir/myname-mystep: /path/to/some/dependency
>@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) \
>--blue --bold \
>--progress-dir=/path/to/buildir/CMakeFiles \
>--progress-num=$(CMAKE_PROGRESS_9) "My Comment"
>cd /path/to/workingdir && \
>my_COMMAND my_arg1 my_arg2 ... \
>cd /path/to/workingdir && \
>cmake -E touch /path/to/stamp_dir/myname-mystep
>
>Now, I'm not sure about the portability of the COMMAND that
>is passed to ExternalProject_Add_Step. Are we assuming that
>every operating system supports a POSIX (unix) shell, like bash?
>
>Otherwise it seems that the only way to be portable is to run
>cmake in script mode there.
>
>Note how the last command does this: it runs cmake in order to portably
>'touch' the target file (a stamp file).
>
>What I need is way to generate a rule where depending on a
>condition (to be decided by the COMMAND (my_COMMAND)) that
>touch is or is not done.
>
>In the single target target POSIX Makefile case this could look like
>this (I'm leaving out the COMMENT here for brevity),
>
> /path/to/stamp_dir/myname-mystep: /path/to/some/dependency
>(cd /path/to/workingdir && \
>if my_COMMAND my_arg1 my_arg2 ...; then \
>  cmake -E touch /path/to/stamp_dir/myname-mystep; \
>fi)
>
>which uses the return value of my_COMMAND to decide whether or
>not to touch the stamp file.
>
>However, this is pure shell coding: using a '(' to open a sub shell
>and then using 'if ...; then ... fi'.
>
>I'm looking for ideas on how to implement this in a portable way.
>
>How can I extract a boolean from a user defined COMMAND and then
>use that to conditionally execute the touch?
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] Need suggestions for implementation of new feature in cmake.

[Carlo Wood]

Hello!

I'm writing a patch for cmake to address
https://gitlab.kitware.com/cmake/cmake/issues/19703

but I need a little help; I'm only familiar with
GNU/Linux and single target generator Makefile.

In terms of a Makefile, if one uses ExternalProject_Add_Step, see

https://cmake.org/cmake/help/latest/module/ExternalProject.html#explicit-step-management

then something like this is generated:

/path/to/stamp_dir/myname-mystep: /path/to/some/dependency
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) \
--blue --bold \
--progress-dir=/path/to/buildir/CMakeFiles \
--progress-num=$(CMAKE_PROGRESS_9) "My Comment"
cd /path/to/workingdir && \
my_COMMAND my_arg1 my_arg2 ... \
cd /path/to/workingdir && \
cmake -E touch /path/to/stamp_dir/myname-mystep

Now, I'm not sure about the portability of the COMMAND that
is passed to ExternalProject_Add_Step. Are we assuming that
every operating system supports a POSIX (unix) shell, like bash?

Otherwise it seems that the only way to be portable is to run
cmake in script mode there.

Note how the last command does this: it runs cmake in order to portably
'touch' the target file (a stamp file).

What I need is way to generate a rule where depending on a
condition (to be decided by the COMMAND (my_COMMAND)) that
touch is or is not done.

In the single target target POSIX Makefile case this could look like
this (I'm leaving out the COMMENT here for brevity),

 /path/to/stamp_dir/myname-mystep: /path/to/some/dependency
(cd /path/to/workingdir && \
if my_COMMAND my_arg1 my_arg2 ...; then \
  cmake -E touch /path/to/stamp_dir/myname-mystep; \
fi)

which uses the return value of my_COMMAND to decide whether or
not to touch the stamp file.

However, this is pure shell coding: using a '(' to open a sub shell
and then using 'if ...; then ... fi'.

I'm looking for ideas on how to implement this in a portable way.

How can I extract a boolean from a user defined COMMAND and then
use that to conditionally execute the touch?

-- 
Carlo Wood 
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] Dynamic linking for one target only

[Robert Bielik]

Hi all,

I have a system of executables/libraries where all are built with “-static” 
(ARM muslc toolchain). However, I have one shared object target which should be 
linked dynamically. I.e. I get the error:
“attempted static link of dynamic object `lib/libmy_shared_object.so'”

Ideas on how to enforce dynamic linking for one target ?

TIA
/Rob

The information in this email (including any attachments) may contain 
confidential and/or proprietary material. Any review, retransmission or use of 
this information by persons or entities other than the intended, authorized 
recipient is prohibited. If you received this email in error, please notify the 
sender and delete the material. For information regarding how Dirac handles 
personal data, please visit https://www.dirac.com/privacy-policy.
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] [ANNOUNCE] CMake 3.17.0 available for download

[Robert Maynard via CMake]

I am happy to announce that CMake 3.17.0 is now available for download at:
  https://cmake.org/download/

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

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

Some of the more significant changes in CMake 3.17 are:

* "cmake(1)" gained a "Ninja Multi-Config" generator, which is similar
  to the "Ninja" generator but can be used to build multiple
  configurations at once.

* Visual Studio Generators learned to support per-config sources.
  Previously only Command-Line Build Tool Generators supported them.

* The "Compile Features" functionality now offers meta-features for
  the CUDA language standard levels (e.g. "cuda_std_03",
  "cuda_std_14").  See "CMAKE_CUDA_KNOWN_FEATURES".

* The "CMAKE_CUDA_RUNTIME_LIBRARY" variable and "CUDA_RUNTIME_LIBRARY"
  target property were introduced to select the CUDA runtime library
  used when linking targets that use CUDA.

* The "FindCUDAToolkit" module was added to find the CUDA Toolkit
  without enabling CUDA as a language.

* "cmake(1)" gained a "--debug-find" command-line option to enable
  additional human-readable output on where "find_*" commands search.

* The "CMAKE_FIND_DEBUG_MODE" variable was introduced to print extra
  "find_*" call information during the cmake run to standard error.
  Output is designed for human consumption and not for parsing.

* The "FindCURL" module learned to find CURL using the
  "CURLConfig.cmake" package configuration file generated by CURL’s
  cmake buildsystem.  It also gained a new "CURL_NO_CURL_CMAKE" option
  to disable this behavior.

* The "FindPython" module has learned to find Python components in
  active virtual environments managed by "conda".

* The "ctest(1)" tool gained a "--no-tests=<[error|ignore]>" option to
  explicitly set and unify the behavior between direct invocation and
  script mode if no tests were found.

* The "ctest(1)" tool gained a "--repeat :" option to specify
  conditions in which to repeat tests.  This generalizes the existing
  "--repeat-until-fail " option to add modes for "until-pass" and
  "after-timeout".

* Target link properties "INTERFACE_LINK_OPTIONS",
  "INTERFACE_LINK_DIRECTORIES" and "INTERFACE_LINK_DEPENDS" are now
  transitive over private dependencies on static libraries. See policy
  "CMP0099".

* When using MinGW tools, the "find_library()" command no longer finds
  ".dll" files by default.  Instead, it expects ".dll.a" import
  libraries to be available.

* The "Ninja" generator now prefers the first ninja build tool to
  appear in the "PATH" no matter whether it is called "ninja-build",
  "ninja", or "samu".  Previously the first of those names to appear
  anywhere in the "PATH" would be preferred.

* "cmake(1)" gained a "-E rm" command-line tool that can be used to
  remove directories and files.  This supersedes the existing "-E
  remove" and "-E remove_directory" tools and has better semantics.


CMake 3.17 Release Notes


Changes made since CMake 3.16 include the following.


New Features



Generators
--

* "cmake(1)" gained a "Ninja Multi-Config" generator, which is similar
  to the "Ninja" generator but can be used to build multiple
  configurations at once.

* Visual Studio Generators learned to support per-config sources.
  Previously only Command-Line Build Tool Generators supported them.

* Visual Studio Generators for VS 2010 and above now support
  specifying the "VCTargetsPath" value for project files in
  "CMAKE_GENERATOR_TOOLSET" setting.

* Visual Studio Generators for VS 2010 and above learned to support
  .NET Standard and .NET Core.  See the "DOTNET_TARGET_FRAMEWORK"
  target property and associated "CMAKE_DOTNET_TARGET_FRAMEWORK"
  variable.


Languages
-

* The "Compile Features" functionality now offers meta-features for
  the CUDA language standard levels (e.g. "cuda_std_03",
  "cuda_std_14").  See "CMAKE_CUDA_KNOWN_FEATURES".


Compilers
-

* The IBM XL Fortran compiler is now supported by the "Ninja"
  generator.


Command-Line


* "cmake(1)" gained a "--debug-find" command-line option to enable
  additional human-readable output on where "find_*" commands search.

* "cmake(1)" gained a "--trace-format" command-line option that can be
  used to set the "--trace" output format. Currently, the old human
  readable and the new JSON format are supported. The new JSON format
  is easier to parse automatically than the existing format.

* "cmake(1)" gained a "-E rm" command-line tool that can be used to
  remove directories and files.  This supersedes the existing "-E
  remove" and "-E remove_directory" tools and has better semantics.


Commands


* The "add_custom_command()" command learned to interpret paths in
  "DEPENDS" arguments that are specified relative to the current
  binary directory.

* The "foreach()" command learned a new "ZIP_LISTS" option 

[CMake] Unable to debug Qt app in Xcode

[Roman Wüger]

Hello,

with a simple GUI Qt application I’m unable to stop at a given breakpoint.

Could it be that the xcodeproj is not generated correctly?

I’m using cmake 3.16, Qt 5.14.1 and Xcode 11.3.1 on Catalina 10.15.3

Thanks in advance 

Best Regards
Roman
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] Preferred way to deploy Qt app to Mac App Store

[Roman Wüger]

Hello,

What is at the moment the preferred way to deploy a Qt app to the Mac App Store 
and to the iOS App Store ?

Thanks in advance 

Best Regards
Roman
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] What is the difference between STATIC and INTERNAL cache variables?

[Timothy Wrona]

According to the documentation:

https://cmake.org/cmake/help/v3.17/prop_cache/TYPE.html

It looks like STATIC cache variables are supposed to be visible from the
CMake GUI, but not modifiable. But when I open a project that has some
STATIC variables in the CMake GUI it looks like you can't even see them at
all (similar to INTERNAL cache variables).

In fact, other than being declared "STATIC" in the "CMakeCache.txt" file I
can't see any real difference between these variables and INTERNAL
variables.

Is there any difference between STATIC and INTERNAL cache variables in
practice?

Thanks,
Tim
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] [ANNOUNCE] CMake 3.17.0-rc3 is ready for testing

[Robert Maynard via CMake]

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

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

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

Some of the more significant changes in CMake 3.17 are:

* "cmake(1)" gained a "Ninja Multi-Config" generator, which is similar
  to the "Ninja" generator but can be used to build multiple
  configurations at once.

* Visual Studio Generators learned to support per-config sources.
  Previously only Command-Line Build Tool Generators supported them.

* The "Compile Features" functionality now offers meta-features for
  the CUDA language standard levels (e.g. "cuda_std_03",
  "cuda_std_14").  See "CMAKE_CUDA_KNOWN_FEATURES".

* The "CMAKE_CUDA_RUNTIME_LIBRARY" variable and "CUDA_RUNTIME_LIBRARY"
  target property were introduced to select the CUDA runtime library
  used when linking targets that use CUDA.

* The "FindCUDAToolkit" module was added to find the CUDA Toolkit
  without enabling CUDA as a language.

* "cmake(1)" gained a "--debug-find" command-line option to enable
  additional human-readable output on where "find_*" commands search.

* The "CMAKE_FIND_DEBUG_MODE" variable was introduced to print extra
  "find_*" call information during the cmake run to standard error.
  Output is designed for human consumption and not for parsing.

* The "FindCURL" module learned to find CURL using the
  "CURLConfig.cmake" package configuration file generated by CURL’s
  cmake buildsystem.  It also gained a new "CURL_NO_CURL_CMAKE" option
  to disable this behavior.

* The "FindPython" module has learned to find Python components in
  active virtual environments managed by "conda".

* The "ctest(1)" tool gained a "--no-tests=<[error|ignore]>" option to
  explicitly set and unify the behavior between direct invocation and
  script mode if no tests were found.

* The "ctest(1)" tool gained a "--repeat :" option to specify
  conditions in which to repeat tests.  This generalizes the existing
  "--repeat-until-fail " option to add modes for "until-pass" and
  "after-timeout".

* Target link properties "INTERFACE_LINK_OPTIONS",
  "INTERFACE_LINK_DIRECTORIES" and "INTERFACE_LINK_DEPENDS" are now
  transitive over private dependencies on static libraries. See policy
  "CMP0099".

* When using MinGW tools, the "find_library()" command no longer finds
  ".dll" files by default.  Instead, it expects ".dll.a" import
  libraries to be available.

* The "Ninja" generator now prefers the first ninja build tool to
  appear in the "PATH" no matter whether it is called "ninja-build",
  "ninja", or "samu".  Previously the first of those names to appear
  anywhere in the "PATH" would be preferred.

* "cmake(1)" gained a "-E rm" command-line tool that can be used to
  remove directories and files.  This supersedes the existing "-E
  remove" and "-E remove_directory" tools and has better semantics.


CMake 3.17 Release Notes


Changes made since CMake 3.16 include the following.


New Features



Generators
--

* "cmake(1)" gained a "Ninja Multi-Config" generator, which is similar
  to the "Ninja" generator but can be used to build multiple
  configurations at once.

* Visual Studio Generators learned to support per-config sources.
  Previously only Command-Line Build Tool Generators supported them.

* Visual Studio Generators for VS 2010 and above now support
  specifying the "VCTargetsPath" value for project files in
  "CMAKE_GENERATOR_TOOLSET" setting.

* Visual Studio Generators for VS 2010 and above learned to support
  .NET Standard and .NET Core.  See the "DOTNET_TARGET_FRAMEWORK"
  target property and associated "CMAKE_DOTNET_TARGET_FRAMEWORK"
  variable.


Languages
-

* The "Compile Features" functionality now offers meta-features for
  the CUDA language standard levels (e.g. "cuda_std_03",
  "cuda_std_14").  See "CMAKE_CUDA_KNOWN_FEATURES".


Compilers
-

* The IBM XL Fortran compiler is now supported by the "Ninja"
  generator.


Command-Line


* "cmake(1)" gained a "--debug-find" command-line option to enable
  additional human-readable output on where "find_*" commands search.

* "cmake(1)" gained a "--trace-format" command-line option that can be
  used to set the "--trace" output format. Currently, the old human
  readable and the new JSON format are supported. The new JSON format
  is easier to parse automatically than the existing format.

* "cmake(1)" gained a "-E rm" command-line tool that can be used to
  remove directories and files.  This supersedes the existing "-E
  remove" and "-E remove_directory" tools and has better semantics.


Commands


* The "add_custom_command()" command learned to interpret paths in
  "DEPENDS" arguments that are specified relative to the current
  binary directory.

* The "foreach()" command learned a new "ZIP_LISTS" option to iterate
 

[CMake] Scoping of CMake functions included from modules

[Timothy Wrona]

I've been working on a relatively complicated project that uses multiple
CMake modules. Some of these modules internally include other modules. The
issue is, when one of my modules internally includes another module, all of
the functions from the internal module become visible globally throughout
my whole project!

I have written a Stack Overflow problem with a basic example demonstrating
my problem:
https://stackoverflow.com/questions/60626239/how-can-i-scope-a-cmake-function-so-it-cant-be-accessed-from-outside-a-file


Unfortunately CMake doesn't get much response on Stack Overflow so I
figured I should probably send a message to the mailing list as well.

Does anyone know how to resolve this problem?

Thanks,
Tim
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] Windows build behavior change

[J Decker]

I'm building this new windows system... I installed the latest cmake
I'm attempting to build this project with visual studio
1) it couldn't find an assembler until I put gcc in the path (i'm not sure
what part is requiring assembly I'll dig into that later)  I added NASM to
the path, and that didn't help.

2) I've been specifying libraries to link against as just their name in my
cmakelists files; so that I can build with gcc and get 'libodbc32.a' or
MSVC and get 'odbc32.lib'  but the .lib extension isn't being added to the
libraries specifed in the generated VS(2019) project files
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] find_package to find Cygwin versions of Flex and Bison

[Stephen Morris]

Thank you; prepending C:/cygwin64/bin To CMAKE_PROGRAM_PATH was all I needed to 
do to fix the problem.

-Original Message-
Date: Thu, 5 Mar 2020 14:28:27 +0100
From: Eric Doenges 

You can prepend C:\cygwin64\bin to the CMAKE_PROGRAM_PATH variable so that it 
looks there first.? While the find_package documentation does not mention 
CMAKE_PROGRAM_PATH, I know this works for bison and flex because that is what 
we do in our project (presumably, find_program is used internally within the 
find_package, explaining why CMAKE_PROGRAM_PATH is considered).

You could also try setting the FLEX_ROOT and BISON_ROOT variables to 
C:\cygwin64\bin or perhaps C:\cygwin64. According to the find_package 
documentation, this should allow you to set the search location on a 
per-package basis. However, I have not had this work for me, so your mileage 
may vary.

Am 05.03.20 um 12:12 schrieb Stephen Morris:
> To compile my application I need to use the Flex and Bison 
> applications. To compile under Linux, all I need to do in my 
> CMakeLists.txt file to find them is
>
>  find_package(FLEX REQUIRED)
>  find_package(BISON REQUIRED)
>
> ...and everything works as expected.
>
> In Windows, however, I'm using the Cygwin versions of Flex and Bison which 
> are installed in C:\cygwin64\bin. This doesn't seem to be on the path that 
> find_package searches in Module Mode, so the search returns unsuccessfully.
>
> However, if I try to tell find_package where to look, viz.
>
>  find_package(FLEX REQUIRED PATHS C:/cygwin64/bin NO_DEFAULT_PATH)
>  find_package(BISON REQUIRED PATHS C:/cygwin64/bin 
> NO_DEFAULT_PATH)
>
> ...then by adding the PATHS keyword I've invoked Config mode and I get an 
> error message saying:
>
>  Could not find a package configuration file provided by "FLEX" with any 
> of
>  the following names
>
>  FLEXConfig.cmake
>  flex-config.cmake
>
> ...because sure enough Cygwin does not provide these files.
>
> So what can I do? Ideally I'd like to use Module Mode but provide a path 
> hint; but there seems no way to do that.
>
> At the moment I can only think of:
> (a) Hard-coding add_custom_target commands to invoke flex and bison 
> entirely manually when they're needed, or
> (b) Writing my own FLEXConfig.cmake and BISONConfig.cmake files for use in 
> Config Mode.
>
> Both of these seem disproportionately difficult for what seems to me like it 
> ought to be a common and simple problem. So is there a better solution that 
> I'm missing?
>
*Dr. Eric D?nges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany doen...@mvtec.com 
 | Tel: +49 89 457 695-0 | www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] find_package to find Cygwin versions of Flex and Bison in Windows

[Eric Doenges]

You can prepend C:\cygwin64\bin to the CMAKE_PROGRAM_PATH variable so 
that it looks there first.  While the find_package documentation does 
not mention CMAKE_PROGRAM_PATH, I know this works for bison and flex 
because that is what we do in our project (presumably, find_program is 
used internally within the find_package, explaining why 
CMAKE_PROGRAM_PATH is considered).


You could also try setting the FLEX_ROOT and BISON_ROOT variables to 
C:\cygwin64\bin or perhaps C:\cygwin64. According to the find_package 
documentation, this should allow you to set the search location on a 
per-package basis. However, I have not had this work for me, so your 
mileage may vary.


Am 05.03.20 um 12:12 schrieb Stephen Morris:

To compile my application I need to use the Flex and Bison applications. To 
compile under Linux, all I need to do in my CMakeLists.txt file to find them is

 find_package(FLEX REQUIRED)
 find_package(BISON REQUIRED)

...and everything works as expected.

In Windows, however, I'm using the Cygwin versions of Flex and Bison which are 
installed in C:\cygwin64\bin. This doesn't seem to be on the path that 
find_package searches in Module Mode, so the search returns unsuccessfully.

However, if I try to tell find_package where to look, viz.

 find_package(FLEX REQUIRED PATHS C:/cygwin64/bin NO_DEFAULT_PATH)
 find_package(BISON REQUIRED PATHS C:/cygwin64/bin NO_DEFAULT_PATH)

...then by adding the PATHS keyword I've invoked Config mode and I get an error 
message saying:

 Could not find a package configuration file provided by "FLEX" with any of
 the following names

 FLEXConfig.cmake
 flex-config.cmake

...because sure enough Cygwin does not provide these files.

So what can I do? Ideally I'd like to use Module Mode but provide a path hint; 
but there seems no way to do that.

At the moment I can only think of:
(a) Hard-coding add_custom_target commands to invoke flex and bison entirely 
manually when they're needed, or
(b) Writing my own FLEXConfig.cmake and BISONConfig.cmake files for use in 
Config Mode.

Both of these seem disproportionately difficult for what seems to me like it 
ought to be a common and simple problem. So is there a better solution that I'm 
missing?


*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 | 
www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] find_package to find Cygwin versions of Flex and Bison in Windows

[Stephen Morris]

To compile my application I need to use the Flex and Bison applications. To 
compile under Linux, all I need to do in my CMakeLists.txt file to find them is

find_package(FLEX REQUIRED)
find_package(BISON REQUIRED)

...and everything works as expected.

In Windows, however, I'm using the Cygwin versions of Flex and Bison which are 
installed in C:\cygwin64\bin. This doesn't seem to be on the path that 
find_package searches in Module Mode, so the search returns unsuccessfully.

However, if I try to tell find_package where to look, viz.

find_package(FLEX REQUIRED PATHS C:/cygwin64/bin NO_DEFAULT_PATH)
find_package(BISON REQUIRED PATHS C:/cygwin64/bin NO_DEFAULT_PATH)

...then by adding the PATHS keyword I've invoked Config mode and I get an error 
message saying:

Could not find a package configuration file provided by "FLEX" with any of 
the following names

FLEXConfig.cmake
flex-config.cmake

...because sure enough Cygwin does not provide these files.

So what can I do? Ideally I'd like to use Module Mode but provide a path hint; 
but there seems no way to do that.

At the moment I can only think of:
(a) Hard-coding add_custom_target commands to invoke flex and bison entirely 
manually when they're needed, or
(b) Writing my own FLEXConfig.cmake and BISONConfig.cmake files for use in 
Config Mode.

Both of these seem disproportionately difficult for what seems to me like it 
ought to be a common and simple problem. So is there a better solution that I'm 
missing?

-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] copying fortran .mod files in different directories

[Lukas van de Wiel]

Hi Bill,

Thanks a lot for your quick response! Using your idea I could set the
Fortran module directory per module target, and add those directories as
target_include_directories to the executables. Worked like a charm!

Lukas

PS. As example, I adapted my cat/dog CMakeLists.txt to this to get to work,
in parallel build 'n all:

project(pets LANGUAGES Fortran)

file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/catdir)
file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/dogdir)

set(catdir "${CMAKE_BINARY_DIR}/catdir")
set(dogdir "${CMAKE_BINARY_DIR}/dogdir")

set(CMAKE_Fortran_SOURCE_FILES_EXTENSIONS F)
set(CMAKE_Fortran_FLAGS "-cpp -std=f2008 -ffree-form")

add_library(catModule STATIC "src/pets.F")
target_compile_options(catModule PUBLIC "-Dcat")
set_target_properties(catModule PROPERTIES Fortran_MODULE_DIRECTORY
${catdir})

add_library(dogModule STATIC "src/pets.F")
set_target_properties(dogModule PROPERTIES Fortran_MODULE_DIRECTORY
${dogdir})

add_executable(cat "src/main.F")
target_include_directories(cat PUBLIC ${catdir})
add_dependencies(cat catModule)
target_link_libraries(cat catModule)
target_compile_options(cat PUBLIC "-Dcat")

add_executable(dog "src/main.F")
target_include_directories(dog PUBLIC ${dogdir})
add_dependencies(dog dogModule)
target_link_libraries(dog dogModule)







On Wed, Mar 4, 2020 at 11:10 AM Bill Somerville 
wrote:

> On 04/03/2020 09:24, Lukas van de Wiel wrote:
> > we are running a Fortran code containing several dozen modules. These
> > are build in two versions, differentiated by #ifdef statements. The
> > archive files of the two versions are being kept apart by different
> > file names, but the .mod files have fixed names, based on the name of
> > the module. During a parallel build, a .mod file of one version may be
> > overwritten by the partner .mod file while the first one is still
> > required by other bits of ode that depends on it.
> >
> > To circumvent it, I wrote .mod files of each variety in their own
> > directory using
> >
> > target_compile_option(moduleTarget PUBLIC -JdirectoryName)
> >
> Hi Lukas,
>
> we do something similar. We have it working by setting the target
> property Fortran_MODULE_DIRECTORY, in our case that is on a static
> library which contains the Fortran object code. We have two versions,
> one built with OpenMP and another without. One library has a default
> module directory and for the other we set the property above to a
> sub-directory of the binary directory, e.g.
> "set_target_properties(, Fortran_MODULE_DIRECTORY,
> ${CMAKE_BINARY_DIR}/fortran_modules_omp)". We also set the property on
> the final executables where required so I assume it does not propagate
> outwards from the static library to executables linking it :(
>
> Regards
> Bill Somerville.
>
> --
>
> Powered by kitware.com/cmake
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit https://cmake.org/services
>
> Visit other Kitware open-source projects at
> https://www.kitware.com/platforms
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
> This mailing list is deprecated in favor of https://discourse.cmake.org
>
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] [ANNOUNCE] CMake 3.16.5 available for download

[Robert Maynard via CMake]

We are pleased to announce that CMake 3.16.5 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.16.5 since 3.16.4:

Brad King (5):
  libarchive: Fix WideCharToMultiByte output buffer size
  libarchive: Add support for UTF-8 locale on Windows
  Propagate backtraces from LINK_LIBRARIES through to link line items
  Help: Update CMake 3.16 release notes for 3.16.5
  CMake 3.16.5

Francisco Facioni (1):
  Ninja: Do not use nvcc response files with non-nvcc tools

Kyle Edwards (1):
  install: Fix regression when using default destinations

Marc Chevrier (2):
  FindPython: Mark non-public cache entries INTERNAL in CMake 3.16
  FindPython: Do not cache computed result variables in CMake 3.16

Rolf Eike Beer (1):
  FindPkgConfig: set policies CMP0054 and CMP0057 to new
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] copying fortran .mod files in different directories

[Bill Somerville]

On 04/03/2020 09:24, Lukas van de Wiel wrote:
we are running a Fortran code containing several dozen modules. These 
are build in two versions, differentiated by #ifdef statements. The 
archive files of the two versions are being kept apart by different 
file names, but the .mod files have fixed names, based on the name of 
the module. During a parallel build, a .mod file of one version may be 
overwritten by the partner .mod file while the first one is still 
required by other bits of ode that depends on it.


To circumvent it, I wrote .mod files of each variety in their own 
directory using


target_compile_option(moduleTarget PUBLIC -JdirectoryName)


Hi Lukas,

we do something similar. We have it working by setting the target 
property Fortran_MODULE_DIRECTORY, in our case that is on a static 
library which contains the Fortran object code. We have two versions, 
one built with OpenMP and another without. One library has a default 
module directory and for the other we set the property above to a 
sub-directory of the binary directory, e.g. 
"set_target_properties(, Fortran_MODULE_DIRECTORY, 
${CMAKE_BINARY_DIR}/fortran_modules_omp)". We also set the property on 
the final executables where required so I assume it does not propagate 
outwards from the static library to executables linking it :(


Regards
Bill Somerville.

--

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] copying fortran .mod files in different directories

[Lukas van de Wiel]

Dear more experienced cmake user,

we are running a Fortran code containing several dozen modules. These are
build in two versions, differentiated by #ifdef statements. The archive
files of the two versions are being kept apart by different file names, but
the .mod files have fixed names, based on the name of the module. During a
parallel build, a .mod file of one version may be overwritten by the
partner .mod file while the first one is still required by other bits of
ode that depends on it.

To circumvent it, I wrote .mod files of each variety in their own directory
using

target_compile_option(moduleTarget PUBLIC -JdirectoryName)

but then, during the copy phase, cmake cannot find the module, because I
circumvented the cmake way with the -J option of gfortran, which gives the
option to direct .mod files to a different directory, which works, but when
those modules are actually used, I get:

Error copying Fortran module "modulename.mod. Tried "MODULENAME.mod" and
"modulename.mod"

To illustrate the problem I have written a simple test case that is
conceptually the same, that consist of two tiny Fortran snippets and the
CMakeLists.txt failing to build it. In this simple case, the program is
idiotic. It has a cat version and a dog version, and it does the cat
variety with -Dcat, otherwise it does the dog variety. cmake runs well, but
making shows cmake in trouble:

>make VERBOSE=1
.
.
/usr/bin/cmake -E cmake_copy_f90_mod pets.mod
CMakeFiles/dogModule.dir/pets.mod.stamp GNU
Error copying Fortran module "pets.mod".  Tried "PETS.mod" and "pets.mod".

So in short, how can the location of these .mod files in a target specific
version, in stead of with the generic
CMAKE_Fortran_MODULE_DIRECTORY that will just cause the /mod files to
overwrite each other in a different directory?

Also adding the directories where the mod files are as target specific
include directories does not help cmake...

I am very curious what would be the cmake way of doing this properly.

Thank you very much for your time and expertise!

Lukas

 the module file; pets.F

module pets
implicit none
contains

#ifdef cat
subroutine cattalk()
write(*,*) "meow"
#else
subroutine dogtalk()
write(*,*) "woof"
#endif
end subroutine

end module

 the main.F

program main
#ifdef cat
use pets, only: cattalk
implicit none
call cattalk()
#else
use pets, only: dogtalk
implicit none
call dogtalk()
#endif
end program

 and CMakeLists.txt

project(pets LANGUAGES Fortran)

file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/catdir)
file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/dogdir)

set(catdir ${CMAKE_BINARY_DIR}/catdir)
set(dogdir ${CMAKE_BINARY_DIR}/dogdir)

set(CMAKE_Fortran_SOURCE_FILES_EXTENSIONS F)
set(CMAKE_Fortran_FLAGS "-cpp -std=f2008 -ffree-form")

add_library(catModule STATIC "src/pets.F")
target_compile_options(catModule PUBLIC "-Dcat -J${catdir}")

add_library(dogModule STATIC "src/pets.F")
target_compile_options(dogModule PUBLIC "-J${dogdir}")

add_executable(cat "src/main.F")
add_dependencies(cat catModule)
target_link_libraries(cat catModule)
target_compile_options(cat PUBLIC "-Dcat")

add_executable(dog "src/main.F")
add_dependencies(dog dogModule)
target_link_libraries(dog dogModule)


-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] Setting rpath via LDFLAGS environment variable

[Sergei Nikulov]

вт, 3 мар. 2020 г. в 07:52, Ray Satiro via CMake :
>
> I am building libssh with cmake. I have two versions of OpenSSL on my
> system and need libssh to use the later version of OpenSSL, which is in
> /usr/local/ssl/lib. I need that rpath both before and after install, as
> libssh should always use that version of OpenSSL. To do that I've been
> passing LDFLAGS:
>
> cmake -E env LDFLAGS="-Wl,-rpath=/usr/local/ssl/lib" cmake
> -DCMAKE_BUILD_TYPE=RelWithDebInfo -DUNIT_TESTING=ON
> -DCMAKE_INSTALL_PREFIX=/usr/local -DOPENSSL_ROOT_DIR=/usr/local/ssl
> -DCMAKE_BUILD_TYPE=Debug ..
>
> That works fine, but on install cmake says:
>
> -- Set runtime path of "/usr/local/lib/libssh.so.4.8.1" to ""
>
> However the rpath actually is in the file:
>
> objdump -x /usr/local/lib/libssh.so.4.8.1 | grep RPATH
>  ?? RPATH?? /usr/local/ssl/lib
>
> Is the message from cmake a bug or if not then is there a better way to
> pass rpath from the command line?
>

Ray,

CMake mailing list migrated to https://discourse.cmake.org/, so could
you please ask a question in the forum?
Regarding RPATH handling/defining
https://cmake.org/cmake/help/v3.17/search.html?q=RPATH
I think you should check CMAKE_INSTALL_RPATH and leave LD_FLAGS unchanged.

> --
>
> Powered by kitware.com/cmake
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit https://cmake.org/services
>
> Visit other Kitware open-source projects at https://www.kitware.com/platforms
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
> This mailing list is deprecated in favor of https://discourse.cmake.org

-- 
Best Regards,
Sergei Nikulov
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] Setting rpath via LDFLAGS environment variable

[Ray Satiro via CMake]

I am building libssh with cmake. I have two versions of OpenSSL on my 
system and need libssh to use the later version of OpenSSL, which is in 
/usr/local/ssl/lib. I need that rpath both before and after install, as 
libssh should always use that version of OpenSSL. To do that I've been 
passing LDFLAGS:


cmake -E env LDFLAGS="-Wl,-rpath=/usr/local/ssl/lib" cmake 
-DCMAKE_BUILD_TYPE=RelWithDebInfo -DUNIT_TESTING=ON 
-DCMAKE_INSTALL_PREFIX=/usr/local -DOPENSSL_ROOT_DIR=/usr/local/ssl 
-DCMAKE_BUILD_TYPE=Debug ..


That works fine, but on install cmake says:

-- Set runtime path of "/usr/local/lib/libssh.so.4.8.1" to ""

However the rpath actually is in the file:

objdump -x /usr/local/lib/libssh.so.4.8.1 | grep RPATH
?? RPATH?? /usr/local/ssl/lib

Is the message from cmake a bug or if not then is there a better way to 
pass rpath from the command line?


--

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] [ANNOUNCE] CMake 3.17.0-rc2 is ready for testing

[Robert Maynard via CMake]

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

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

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

Some of the more significant changes in CMake 3.17 are:

* "cmake(1)" gained a "Ninja Multi-Config" generator, which is similar
  to the "Ninja" generator but can be used to build multiple
  configurations at once.

* Visual Studio Generators learned to support per-config sources.
  Previously only Command-Line Build Tool Generators supported them.

* The "Compile Features" functionality now offers meta-features for
  the CUDA language standard levels (e.g. "cuda_std_03",
  "cuda_std_14").  See "CMAKE_CUDA_KNOWN_FEATURES".

* The "CMAKE_CUDA_RUNTIME_LIBRARY" variable and "CUDA_RUNTIME_LIBRARY"
  target property were introduced to select the CUDA runtime library
  used when linking targets that use CUDA.

* The "FindCUDAToolkit" module was added to find the CUDA Toolkit
  without enabling CUDA as a language.

* "cmake(1)" gained a "--debug-find" command-line option to enable
  additional human-readable output on where find commands search.

* The "CMAKE_FIND_DEBUG_MODE" variable was introduced to print extra
  find call information during the cmake run to standard error. Output
  is designed for human consumption and not for parsing.

* The "FindCURL" module learned to find CURL using the
  "CURLConfig.cmake" package configuration file generated by CURL’s
  cmake buildsystem.  It also gained a new "CURL_NO_CURL_CMAKE" option
  to disable this behavior.

* The "FindPython" module has learned to find Python components in
  active virtual environments managed by "conda".

* The "ctest(1)" tool gained a "--no-tests=<[error|ignore]>" option to
  explicitly set and unify the behavior between direct invocation and
  script mode if no tests were found.

* The "ctest(1)" tool gained a "--repeat :" option to specify
  conditions in which to repeat tests.  This generalizes the existing
  "--repeat-until-fail " option to add modes for "until-pass" and
  "after-timeout".

* Target link properties "INTERFACE_LINK_OPTIONS",
  "INTERFACE_LINK_DIRECTORIES" and "INTERFACE_LINK_DEPENDS" are now
  transitive over private dependencies on static libraries. See policy
  "CMP0099".

* When using MinGW tools, the "find_library()" command no longer finds
  ".dll" files by default.  Instead it expects ".dll.a" import
  libraries to be available.

* The "Ninja" generator now prefers the first ninja build tool to
  appear in the "PATH" no matter whether it is called "ninja-build",
  "ninja", or "samu".  Previously the first of those names to appear
  anywhere in the "PATH" would be preferred.

* "cmake(1)" gained a "-E rm" command-line tool that can be used to
  remove directories and files.  This supersedes the existing "-E
  remove" and "-E remove_directory" tools and has better semantics.


CMake 3.17 Release Notes


Changes made since CMake 3.16 include the following.


New Features



Generators
--

* "cmake(1)" gained a "Ninja Multi-Config" generator, which is similar
  to the "Ninja" generator but can be used to build multiple
  configurations at once.

* Visual Studio Generators learned to support per-config sources.
  Previously only Command-Line Build Tool Generators supported them.

* Visual Studio Generators for VS 2010 and above now support
  specifying the "VCTargetsPath" value for project files in
  "CMAKE_GENERATOR_TOOLSET" setting.

* Visual Studio Generators for VS 2010 and above learned to support
  .NET Standard and .NET Core.  See the "DOTNET_TARGET_FRAMEWORK"
  target property and associated "CMAKE_DOTNET_TARGET_FRAMEWORK"
  variable.


Languages
-

* The "Compile Features" functionality now offers meta-features for
  the CUDA language standard levels (e.g. "cuda_std_03",
  "cuda_std_14").  See "CMAKE_CUDA_KNOWN_FEATURES".


Compilers
-

* The IBM XL Fortran compiler is now supported by the "Ninja"
  generator.


Command-Line


* "cmake(1)" gained a "--debug-find" command-line option to enable
  additional human-readable output on where find commands search.

* "cmake(1)" gained a "--trace-format" command-line option that can be
  used to set the "--trace" output format. Currently, the old human
  readable and the new JSON format are supported. The new JSON format
  is easier to parse automatically, than the existing format.

* "cmake(1)" gained a "-E rm" command-line tool that can be used to
  remove directories and files.  This supersedes the existing "-E
  remove" and "-E remove_directory" tools and has better semantics.


Commands


* The "add_custom_command()" command learned to interpret paths in
  "DEPENDS" arguments that are specified relative to the current
  binary directory.

* The "foreach()" learned a new option "ZIP_LISTS" to iterate over
  multiple 

Re: [CMake] Build cmake dependency

[Scott Bloom]

You may want to move this to https://discourse.cmake.org/, as this mailing list 
is going away (note, Im not with the cmake org at all.. just a user..)

That said,typically, when a CMake based library is included into a larger cmake 
project, it will set some variables.  SUBLIB_DIR for instance..  so you would 
then, in the top project do something like

include_directories( ${SUBLIB_DIR }/include )

If it doesn't create the directory, I would do the following

set( SUBLIB_DIR ${CMAKE_SOURCE_DIR}/SubLibName )
add_subdirectory( ${SUBLIB_DIR} )

for the output of the library, you can in your executable target_link_libraries 
directly list the target project name

target_link_libraries( MyExe SubLib )

Scott

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Pietro Paolini
Sent: Friday, February 28, 2020 1:19 AM
To: cmake@cmake.org
Subject: [CMake] Build cmake dependency

Hi all,

I really cannot say I am an expert with CMake however I have been using it for 
a while now, even though mainly by copying and pasting snippet of code from the 
web therefore not understanding things properly.

I am working on a project which depends on a libary which is itself built using 
CMake, I'd like my project to build the library itself during its own build and 
I can successfully do that by adding the folder to the root CMakeLists.txt of 
my current prject, however I couldn't find a way to include its headers and 
link the shared object.

I had to resort to a bash script which compiles and installs the dependency in 
a pre-defined location and add such location to my project's CMake's setting 
file through the use of include_directories()/link_directories(). It works but 
I'd like to get CMake to do what I want and not having to find workaroun, I am 
pretty confident I am missing something here, is there a better way to do that ?


Thanks,
Pietro


-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] Build cmake dependency

[Pietro Paolini]

Hi all,

I really cannot say I am an expert with CMake however I have been using 
it for a while now, even though mainly by copying and pasting snippet 
of code from the web therefore not understanding things properly.


I am working on a project which depends on a libary which is itself 
built using CMake, I'd like my project to build the library itself 
during its own build and I can successfully do that by adding the 
folder to the root CMakeLists.txt of my current prject, however I 
couldn't find a way to include its headers and link the shared object.


I had to resort to a bash script which compiles and installs the 
dependency in a pre-defined location and add such location to my 
project's CMake's setting file through the use of 
include_directories()/link_directories(). It works but I'd like to get 
CMake to do what I want and not having to find workaroun, I am pretty 
confident I am missing something here, is there a better way to do that 
?



Thanks,
Pietro


--

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] [REMINDER] CMake transition to discourse

[Robert Maynard via CMake]

Reminder the CMake Discourse forum (   https://discourse.cmake.org )
is the preferred location for CMake questions and discussions. The
current mailman-based mailing lists will be disabled in April 2020,
and their archives will remain available after that.

Reminder for those who prefer email over web forums, the Forum Help
page includes instructions to participate in the forum purely via
email.  Creating topics in the forum via email (and receiving replies)
is supported *with or without* registering a user account.
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] cmake, ccache, CCACHE_BASEDIR: wrong paths in compiler error messages

[Steffen Dettmer]

Hi,

I hope I can still post here? I don't have a "discourse" account.

Let me summarize what we have here. We have projects with some
hunderds CMakeLists.txt. The "main" typically use several
add_subdirectory directives for the use libraries in form of:

  add_subdirectory(${path_lib_a} liba)

For each, cmake creates a subdirectory (such as here "liba") in the
build directory. Normally cmake uses absolute paths, so compiler error
messages contain absolute paths as well.

Now we are also using ccache. Since we use the same libs in many
places, of course we want to share the ccache results. For multiple
builddirs I was not able to get it working, but at least for the case
of multiple sourcedirs that have there builddirs below. This is useful
if several people work on same code (shared ccache) or if you have
several checkouts, for example for similar variants or source code
branches. In most of these cases, many libraries are the same, so
caching in theory should be very effective.

Since ccache also compares compiler arguments of course and it's
include arguments include absolute paths, ccaching across src trees
does not work, so we have to set CCACHE_BASEDIR. Technically cmake
creates a wrapper file used as CMAKE_CXX_COMPILER_LAUNCHER in BUILDDIR
with "export CCACHE_BASEDIR=$TOPSRCDIR" and then calling essentially
"ccache $CXX "$@"". Now ccache works fine across source trees. At the
end of the mail some cmake excerpt in case it is useful.

But unfortunately now IDEs (like Vim, QTCreator...) are unable to jump
to compiler errors, because now the paths are relative to the
directory where the compiler (wrapper) is called. Normally the IDEs
know this from make output:

  make[2]: Entering directory
'/home/sdettmer/work/tisc-src/build/cmake-build-debug-1810'

but unfortunately for "add_subdirectory", cmake uses some own logic
visible only when running make VERBOSE=1, which looks like:

  make[2]: Entering directory
'/home/sdettmer/work/tisc-src/build/cmake-build-debug-1810'
  [ 14%] Building CXX object
  cd /home/sdettmer/work/tisc-src/build/cmake-build-debug-1810/libA
&& /home/sdettmer/work/tisc-src/build/cmake-build-debug-1810/ccache-CXX
/opt/bt/cross/i586-pc-linux-gnu/gcc-4.4.3/usr/bin/i586-pc-linux-gnu-g++
...
-o CMakeFiles/libA.dir/home/sdettmer/work/tisc-src/.../libA/src/File1.cpp.o
 -c /home/sdettmer/work/tisc-src/.../libA /src/File1.cpp


Compiler errrors now are not relative to the path told by make (here
cmake-build-debug-1810), but relative to the "cd .../libA", which is
normally not even visible:

  In file included from ../.././libA/File1.cpp:10: 

Now the IDE looks for path relative to cmake-build-debug-1810, because
it does not know about the "cd ...cmake-build-debug-1810/libA" and
does not find the file.

We discussed this in the team, I searched the web for several hours
now, but I don't find any solution. Due to the absolute paths
requirement of cmake I think I must use CCACHE_BASEDIR, but when I do,
IDEs don't find the files. I didn't find a way to make cmake output
"Entering directory" lines. Since we are probably not the only ones
who use cmake and ccache, we probably doing it wrong and miss an
important point.

How is ccache supposed to be used correctly? I saw many examples in
the internet, but none seem to correctly work with CCACHE_BASEDIR, and
without CCACHE_BASEDIR cache is not efficient and almost useless and
shared cache even completely useless (never hits).

Any help appreciated!

As only workaround we could find, I now manually add:

  echo "make[77]: Entering directory '$(pwd)'"

in the ccache-wrapper. This helps a bit, but generates heaps of output
(entering line for each single file) and I think it breaks when using
"make -j".

Steffen

CMakeLists.txt excerpt:

foreach(_BT_LANG "C" "CXX")
file(WRITE "${CMAKE_BINARY_DIR}/ccache-${_BT_LANG}" ""
"#!/bin/sh\n"
"# Xcode generator doesn't include the compiler as the
first arg:\n"
"[ \"$1\" = \"${CMAKE_${_BT_LANG}_COMPILER}\" ] && shift\n"
"\n"
"# \"Convert\" cmake variable to an env to allow
shared caches\n"
"export CCACHE_BASEDIR=${_BT_CCACHE_BASEDIR}\n"
"export CCACHE_SLOPPINESS=file_macro,time_macros\n"
"# export CCACHE_NODIRECT=set\n"
"export CCACHE_CPP2=set\n"
"[ \"\$VERBOSE\" ] && echo \"make[\${MAKELEVEL:-1}]:
Entering directory '$(pwd)'\"\n"
"\"${_BT_${_BT_LANG}_LAUNCHER}\"
\"${CMAKE_${_BT_LANG}_COMPILER}\" \"$@\"\n"
"[ \"\$VERBOSE\" ] && echo \"make[\${MAKELEVEL:-1}]:
Leaving directory '$(pwd)'\"\n"
)
execute_process(COMMAND chmod a+rx
"${CMAKE_BINARY_DIR}/ccache-${_BT_LANG}")
endforeach()
...
CHECK_CXX_COMPILER_FLAG(-fdiagnostics-color=auto
CXX_FLAG_DIAGNOSTIC_COLOR_AUTO)
if 

[CMake] Building Opencv and linking its library as external project

[Kamal Selvam]

Hello,

I started learning CMAKE recently. I am encountering the philosophy of
targets and properties since version 3.0.

I have a project where I should build OpenCV residing in my project folder
as /myproject/third-party/opencv and then link it's library to my own
target.

After searching a lot on stack overflow and internet, I always find CMake
scripts of version < 2.8. Every single answer is unique. I could not find
any proper example of building a third-party libraries the right way,
exporting them and linking them with my own targets.

Could some guide me or post a example of best way to build a external
project like opencv residing inside the project folder and linking it's
library to my own targets.

Thank you,

Best regards,
Kamal
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] exporting and using an exported package in the same project

[Stéphane Ancelot]

Hi,

I am trying to use a third party library 
(https://github.com/zaphoyd/websocketpp)


It exports a Config.cmake file when building , but I want to use it from 
my workspace in which I cloned it .


I tried using find_package(websocketpp CONFIG), but cmake replies 
websocketpp_DIR not found.


The question is: can I use an exported package from the workspace 
exporting it ?


Regards,

S.Ancelot





-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] cmake config. error

[St.Trzaska]

Hello,
please help. I have problem with installing gtest/gmock on MINGW64.
Attachyed are Terminal output and CmakeOutput.log

best regards
St.Trzasak
The system is: MINGW64_NT-10.0-18362 - 3.0.7-338.x86_64 - unknown
Compiling the C compiler identification source file "CMakeCCompilerId.c" 
succeeded.
Compiler: /mingw64/bin/cc.exe 
Build flags: 
Id flags:  

The output was:
0


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
produced "a.exe"

The C compiler identification is GNU, found in 
"/opt/GTest/mybuild/CMakeFiles/3.15.5/CompilerIdC/a.exe"

Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" 
succeeded.
Compiler: /mingw64/bin/CC.exe 
Build flags: 
Id flags:  

The output was:
0


Compilation of the CXX compiler identification source "CMakeCXXCompilerId.cpp" 
produced "a.exe"

The CXX compiler identification is GNU, found in 
"/opt/GTest/mybuild/CMakeFiles/3.15.5/CompilerIdCXX/a.exe"

Determining if the C compiler works passed with the following output:
Change Dir: /opt/GTest/mybuild/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/make.exe cmTC_54db0/fast && /usr/bin/make -f 
CMakeFiles/cmTC_54db0.dir/build.make CMakeFiles/cmTC_54db0.dir/build
make[1]: Wejście do katalogu 
'/opt/GTest/mybuild/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_54db0.dir/testCCompiler.c.obj
/mingw64/bin/cc.exe-o CMakeFiles/cmTC_54db0.dir/testCCompiler.c.obj   -c 
/opt/GTest/mybuild/CMakeFiles/CMakeTmp/testCCompiler.c
Linking C executable cmTC_54db0
/usr/bin/cmake.exe -E cmake_link_script CMakeFiles/cmTC_54db0.dir/link.txt 
--verbose=1
/mingw64/bin/cc.exe  CMakeFiles/cmTC_54db0.dir/testCCompiler.c.obj  -o 
cmTC_54db0 
make[1]: Opuszczenie katalogu 
'/opt/GTest/mybuild/CMakeFiles/CMakeTmp'



Detecting C compiler ABI info compiled with the following output:
Change Dir: /opt/GTest/mybuild/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/make.exe cmTC_62cec/fast && /usr/bin/make -f 
CMakeFiles/cmTC_62cec.dir/build.make CMakeFiles/cmTC_62cec.dir/build
make[1]: Entering directory '/opt/GTest/mybuild/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_62cec.dir/CMakeCCompilerABI.c.obj
/mingw64/bin/cc.exe   -v -o CMakeFiles/cmTC_62cec.dir/CMakeCCompilerABI.c.obj   
-c /usr/share/cmake-3.15.5/Modules/CMakeCCompilerABI.c
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\cc.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-9.2.0/configure --prefix=/mingw64 
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include 
--libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 
--with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++ 
--enable-shared --enable-static --enable-libatomic --enable-threads=posix 
--enable-graphite --enable-fully-dynamic-string 
--enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes 
--disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check 
--enable-lto --enable-libgomp --disable-multilib --enable-checking=release 
--disable-rpath --disable-win32-registry --disable-nls --disable-werror 
--disable-symvers --enable-plugin --with-libiconv --with-system-zlib 
--with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 
--with-isl=/mingw64 --with-pkgversion='Rev2, Built by MSYS2 project' 
--with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 9.2.0 (Rev2, Built by MSYS2 project) 
COLLECT_GCC_OPTIONS='-v' '-o' 
'CMakeFiles/cmTC_62cec.dir/CMakeCCompilerABI.c.obj' '-c' '-mtune=generic' 
'-march=x86-64'
 C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/cc1.exe -quiet -v 
-iprefix C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/ 
-D_REENTRANT C:/msys64/usr/share/cmake-3.15.5/Modules/CMakeCCompilerABI.c 
-quiet -dumpbase CMakeCCompilerABI.c -mtune=generic -march=x86-64 
-auxbase-strip CMakeFiles/cmTC_62cec.dir/CMakeCCompilerABI.c.obj -version -o 
C:\msys64\tmp\ccsrJ3vQ.s
GNU C17 (Rev2, Built by MSYS2 project) version 9.2.0 (x86_64-w64-mingw32)
compiled by GNU C version 9.2.0, GMP version 6.1.2, MPFR version 4.0.2, 
MPC version 1.1.0, isl version isl-0.21-GMP

warning: GMP header version 6.1.2 differs from library version 6.2.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory 
"C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/9.2.0/include"
ignoring nonexistent directory "C:/building/msys64/mingw64/include"
ignoring nonexistent directory "/mingw64/include"
ignoring duplicate directory 
"C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/9.2.0/include-fixed"
ignoring duplicate directory 
"C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory 

[CMake] [ANNOUNCE] CMake 3.17.0-rc1 is ready for testing

[Robert Maynard via CMake]

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

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

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

Some of the more significant changes in CMake 3.17 are:

* "cmake(1)" gained a "Ninja Multi-Config" generator, which is similar
  to the "Ninja" generator but can be used to build multiple
  configurations at once.

* Visual Studio Generators learned to support per-config sources.
  Previously only Command-Line Build Tool Generators supported them.

* The "Compile Features" functionality now offers meta-features for
  the CUDA language standard levels (e.g. "cuda_std_03",
  "cuda_std_14").  See "CMAKE_CUDA_KNOWN_FEATURES".

* The "CMAKE_CUDA_RUNTIME_LIBRARY" variable and "CUDA_RUNTIME_LIBRARY"
  target property were introduced to select the CUDA runtime library
  used when linking targets that use CUDA.

* The "FindCUDAToolkit" module was added to find the CUDA Toolkit
  without enabling CUDA as a language.

* "cmake(1)" gained a "--debug-find" command-line option to enable
  additional human-readable output on where find commands search.

* The "CMAKE_FIND_DEBUG_MODE" variable was introduced to print extra
  find call information during the cmake run to standard error. Output
  is designed for human consumption and not for parsing.

* The "FindCURL" module learned to find CURL using the
  "CURLConfig.cmake" package configuration file generated by CURL’s
  cmake buildsystem.  It also gained a new "CURL_NO_CURL_CMAKE" option
  to disable this behavior.

* The "FindPython" module has learned to find Python components in
  active virtual environments managed by "conda".

* The "ctest(1)" tool gained a "--no-tests=<[error|ignore]>" option to
  explicitly set and unify the behavior between direct invocation and
  script mode if no tests were found.

* The "ctest(1)" tool gained a "--repeat :" option to specify
  conditions in which to repeat tests.  This generalizes the existing
  "--repeat-until-fail " option to add modes for "until-pass" and
  "after-timeout".

* Target link properties "INTERFACE_LINK_OPTIONS",
  "INTERFACE_LINK_DIRECTORIES" and "INTERFACE_LINK_DEPENDS" are now
  transitive over private dependencies on static libraries. See policy
  "CMP0099".

* When using MinGW tools, the "find_library()" command no longer finds
  ".dll" files by default.  Instead it expects ".dll.a" import
  libraries to be available.

* The "Ninja" generator now prefers the first ninja build tool to
  appear in the "PATH" no matter whether it is called "ninja-build",
  "ninja", or "samu".  Previously the first of those names to appear
  anywhere in the "PATH" would be preferred.

* "cmake(1)" gained a "-E rm" command-line tool that can be used to
  remove directories and files.  This supersedes the existing "-E
  remove" and "-E remove_directory" tools and has better semantics.


CMake 3.17 Release Notes


Changes made since CMake 3.16 include the following.


New Features



Generators
--

* "cmake(1)" gained a "Ninja Multi-Config" generator, which is similar
  to the "Ninja" generator but can be used to build multiple
  configurations at once.

* Visual Studio Generators learned to support per-config sources.
  Previously only Command-Line Build Tool Generators supported them.

* Visual Studio Generators for VS 2010 and above now support
  specifying the "VCTargetsPath" value for project files in
  "CMAKE_GENERATOR_TOOLSET" setting.

* Visual Studio Generators for VS 2010 and above learned to support
  .NET Standard and .NET Core.  See the "DOTNET_TARGET_FRAMEWORK"
  target property and associated "CMAKE_DOTNET_TARGET_FRAMEWORK"
  variable.


Languages
-

* The "Compile Features" functionality now offers meta-features for
  the CUDA language standard levels (e.g. "cuda_std_03",
  "cuda_std_14").  See "CMAKE_CUDA_KNOWN_FEATURES".


Compilers
-

* The IBM XL Fortran compiler is now supported by the "Ninja"
  generator.


Command-Line


* "cmake(1)" gained a "--debug-find" command-line option to enable
  additional human-readable output on where find commands search.

* "cmake(1)" gained a "--trace-format" command-line option that can be
  used to set the "--trace" output format. Currently, the old human
  readable and the new JSON format are supported. The new JSON format
  is easier to parse automatically, than the existing format.

* "cmake(1)" gained a "-E rm" command-line tool that can be used to
  remove directories and files.  This supersedes the existing "-E
  remove" and "-E remove_directory" tools and has better semantics.


Commands


* The "add_custom_command()" command learned to interpret paths in
  "DEPENDS" arguments that are specified relative to the current
  binary directory.

* The "foreach()" learned a new option "ZIP_LISTS" to iterate over
  multiple 

Re: [CMake] build step is not thread-safe for CMake

[Eric Doenges]

Am 10.02.20 um 14:23 schrieb Kyle Edwards via CMake:

On Mon, 2020-02-10 at 12:49 +, hex wrote:

hello,

My build step is not thread-safe (the instruction in the COMMAND
part). Every build step depends on one source file:

add_custom_command(
     DEPENDS on_source.file
     OUTPUT
     object_file_for_source_file
     COMMAND not-thread-safe-compiler --build on_source.file
     COMMENT
             "Building Source object"
)

add_custom_target DEPENDS on OUTPUT from all custom command's, but in
order to prevent parallel execution when cmake is called:

cmake --build . --target all -j30

I need to build each step in any order, but still not as a dependency
as this would trigger unnecessary recompilation. Using
MAIN_DEPENDENCY defines hierarchical dependency, but this won't help
in this situation.

I cannot figure out how to prevent parallel execution of COMMAND in
CMake. The only option I see is a single command

add_custom_target(tgt
     DEPENDS on_all_source.files
     COMMAND not-thread-safe-compiler --build on_source1.file
     COMMAND not-thread-safe-compiler --build on_source2.file
     COMMAND not-thread-safe-compiler --build on_source3.file
     . . .
     COMMENT
             "Building target"
)

this would rebuild every source, though.

How do I set this up?

thank you

It sounds like you want order-only dependencies: dependencies the
command waits for before building, but whose changes do not actually
trigger a rebuild. As far as I know, add_custom_command() doesn't have
support for this - perhaps it could be added.


Actually, I think it kind of does, at least with the Ninja generator. If 
you do something like


add_custom_output(OUTPUT fileA COMMAND ...)
add_custom_target(fileA_target DEPENDS fileA)

add_custom_output(OUTPUT fileB DEPENDS fileA COMMAND ...)
add_custom_output(OUTPUT fileC DEPENDS fileA_target COMMAND ...)

then both fileB and fileC will depend on fileA existing, but fileC will 
not be rebuilt if fileA changes, while fileB will be.


Disclaimer - I couldn't find this behavior described in the 
documentation, but it is what I've observed after spending extensive 
amounts of time messing about with add_custom_command() and 
add_custom_target() to build the documentation to our product with CMake 
3.16. Also, I've only tested this with the Ninja generator, so it may 
behave differently with other generators.


With kind regards,
Eric Dönges

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 | 
www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] FindICU.cmake setting ICU_FOUND to "FALSE" with quotes?

[Kent Williams]

I was trying to do this:


find_package(ICU 59.1 QUIET
COMPONENTS
data
i18n
io
tu
uc
)
if(ICU_FOUND)
  include_directories(BEFORE ${ICU_INCLUDE_DIRS})
  message("ICU_LIBRARIES=${ICU_LIBRARIES}")
endif()


And at configuration time, ICU_FOUND was turning up with double quotes 
around it, and as we all know from CMake 101, the string "FALSE" has a 
truth value of TRUE in the if statement.


This is with cmake 3.16.

I fixed this by changing the expression to

IF(ICU_FOUND AND NOT "${ICU_FOUND}" STREQUAL "\"FALSE\"")

but that doesn't seem right somehow!


--

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] build step is not thread-safe for CMake

[Kyle Edwards via CMake]

On Mon, 2020-02-10 at 12:49 +, hex wrote:
> hello,
> 
> My build step is not thread-safe (the instruction in the COMMAND
> part). Every build step depends on one source file:
> 
> add_custom_command(
>     DEPENDS on_source.file
>     OUTPUT
>     object_file_for_source_file
>     COMMAND not-thread-safe-compiler --build on_source.file
>     COMMENT
>             "Building Source object"
> )
> 
> add_custom_target DEPENDS on OUTPUT from all custom command's, but in
> order to prevent parallel execution when cmake is called:
> 
> cmake --build . --target all -j30
> 
> I need to build each step in any order, but still not as a dependency
> as this would trigger unnecessary recompilation. Using
> MAIN_DEPENDENCY defines hierarchical dependency, but this won't help
> in this situation.
> 
> I cannot figure out how to prevent parallel execution of COMMAND in
> CMake. The only option I see is a single command
> 
> add_custom_target(tgt
>     DEPENDS on_all_source.files
>     COMMAND not-thread-safe-compiler --build on_source1.file
>     COMMAND not-thread-safe-compiler --build on_source2.file
>     COMMAND not-thread-safe-compiler --build on_source3.file
>     . . .
>     COMMENT
>             "Building target"
> )
> 
> this would rebuild every source, though.
> 
> How do I set this up?
> 
> thank you

It sounds like you want order-only dependencies: dependencies the
command waits for before building, but whose changes do not actually
trigger a rebuild. As far as I know, add_custom_command() doesn't have
support for this - perhaps it could be added.

This mailing list is deprecated. Please move further discussion to the
Discourse forum:

https://discourse.cmake.org/c/code/11

Kyle
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] build step is not thread-safe for CMake

[hex]

hello,


My build step is not thread-safe (the instruction in the COMMAND part). 
Every build step depends on one source file:



/add_custom_command(//
//    DEPENDS on_source.file//
//    OUTPUT//
//    object_file_for_source_file//
//    COMMAND not-thread-safe-compiler --build on_source.file//
//    COMMENT//
//            "Building Source object"//
//)/


add_custom_target DEPENDS on OUTPUT from all custom command's, but in 
order to prevent parallel execution when cmake is called:



/cmake --build . --target all -j30/


I need to build each step in any order, but still not as a dependency as 
this would trigger unnecessary recompilation. Using MAIN_DEPENDENCY 
defines hierarchical dependency, but this won't help in this situation.



I cannot figure out how to prevent parallel execution of COMMAND in 
CMake. The only option I see is a single command



/add_custom_target(tgt//
//    DEPENDS on_all_source.files//
//    COMMAND not-thread-safe-compiler --build on_source1.file/

/    COMMAND not-thread-safe-compiler --build on_source2.file/

/    COMMAND not-thread-safe-compiler --build on_source3.file/

/    . . .//
/

/    COMMENT//
//            "Building target"//
//)/


this would rebuild every source, though.


How do I set this up?


thank you

-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] CUDA aarch64 cross compile fails to validate nvcc

[Dustyn Blasig]

Hi All,

I'm not sure if people are more active on here or Discourse right now, so
I'm cross-posting. Please reply on the Discourse thread if possible, but
I'll take whatever I can get : )

https://discourse.cmake.org/t/cuda-aarch64-cross-compile-fails-to-validate-nvcc/593

I am stuck trying to make all the CMake pieces happy with the
cross-compile, everything I try makes some part of the flow fail, either
missing flags or tools not be setup properly. Any help much appreciated.

Thanks!
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] Intel ifort Windows cmake_fortran_flags: bug or user error?

[Michael Hirsch, Ph.D.]

I typically "set(CMAKE_Fortran_FLAGS ...)" variable in my CMake
project to set compile flags for all Fortran targets.  Is this
undesired practice?
I haven't had any problems using multiple compilers, *except* for
Intel Ifort on Windows. Ifort on Linux is fine.
Here are the flags that CMake auto-sets for Ifort Windows in
CMAKE_Fortran_FLAGS:

"/W1 /nologo /fpp /libs:dll"

The flag my project needs and that CMake auto-sets is "/libs:dll"
I can workaround this issue by just appending those flags to my flags
in CMAKE_Fortran_FLAGS.

* should I not be setting CMAKE_Fortran_FLAGS manually?
* Is this a CMake "bug" for Ifort on Windows?
* CMake with Ifort on Linux also auto-sets compiler flags like "-fpp"
but doesn't put them in CMAKE_Fortran_FLAGS.
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] [ANNOUNCE] CMake 3.16.4 available for download

[Robert Maynard via CMake]

We are pleased to announce that CMake 3.16.4 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.16.4 since 3.16.3:

Brad King (6):
  ASM_MASM: Populate MSVC runtime library abstraction table
  VS: Tell VS 16.4 not to verify SYMBOLIC custom command inputs
  AIX: Restore pre-3.16 undocumented method to suppress exports with XL
  Android: Fix binutils selection with NDK r19+ unified toolchain
  VS: Do not use native unity builds on VS 2017 versions less than 15.8
  CMake 3.16.4

Kyle Edwards (3):
  file(GET_RUNTIME_DEPENDENCIES): Tolerate empty list arguments
  Help: Add more variable documentation to FindMPI
  CPack: Fix regression in Deb description
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] [ANNOUNCE] CMake 3.15.7 available for download

[Robert Maynard via CMake]

We are pleased to announce that CMake 3.15.7 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.15.7 since 3.15.6:

Brad King (4):
  IRSL: Install msvcp140_{1,2,codecvt_ids}.dll if available
  ASM_MASM: Populate MSVC runtime library abstraction table
  VS: Tell VS 16.4 not to verify SYMBOLIC custom command inputs
  CMake 3.15.7

Robert Maynard (1):
  CUDA: Do not device link if target has no CUDA usage
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] crosscompilation and source generation via add_custom_command

[Jędrzej Dudkiewicz]

On Mon, Feb 3, 2020 at 9:22 PM Hendrik Sattler  wrote:
> Am 3. Februar 2020 20:48:50 MEZ schrieb "Jędrzej Dudkiewicz" 
> :
> >Hello,
> >
> >I cross-compile a project from x86_64-linux-gnu to
> >arm-linux-gnueabihf. Currently this is done using hand-written
> >Makefiles, but I"m moving it to cmake. This project uses custom
> >version of `lemon` parser generator. Aforementioned lemon is included
> >as a source - this is single .c file that is compiled during build. Is
> >there a way to build and run this binary on x86_64-linux-gnu while
> >cross-compiling to arm-linux-gnuabihf? I suppose I could
> >add_custom_command that would compile using hardcoded compiler
> >version, but it doesn't seem very nice.
>
> You can compile the tool using ExternalProject. This needs a separate 
> directory with a its own CMakeLists.txt file for the tool.

Thank you, I will look into it, although I'm not sure if this isn't a
massive overkill in my case.

Thanks!
-- 
Jędrzej Dudkiewicz

I really hate this damn machine, I wish that they would sell it.
It never does just what I want, but only what I tell it.
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] crosscompilation and source generation via add_custom_command

[Hendrik Sattler]

Am 3. Februar 2020 20:48:50 MEZ schrieb "Jędrzej Dudkiewicz" 
:
>Hello,
>
>I cross-compile a project from x86_64-linux-gnu to
>arm-linux-gnueabihf. Currently this is done using hand-written
>Makefiles, but I"m moving it to cmake. This project uses custom
>version of `lemon` parser generator. Aforementioned lemon is included
>as a source - this is single .c file that is compiled during build. Is
>there a way to build and run this binary on x86_64-linux-gnu while
>cross-compiling to arm-linux-gnuabihf? I suppose I could
>add_custom_command that would compile using hardcoded compiler
>version, but it doesn't seem very nice.

You can compile the tool using ExternalProject. This needs a separate directory 
with a its own CMakeLists.txt file for the tool.

>Thanks in advance,
>-- 
>Jędrzej Dudkiewicz
>
>I really hate this damn machine, I wish that they would sell it.
>It never does just what I want, but only what I tell it.
>-- 
>
>Powered by kitware.com/cmake
>
>Kitware offers various services to support the CMake community. For
>more information on each offering, please visit
>https://cmake.org/services
>
>Visit other Kitware open-source projects at
>https://www.kitware.com/platforms
>
>Follow this link to subscribe/unsubscribe:
>https://cmake.org/mailman/listinfo/cmake
>
>This mailing list is deprecated in favor of https://discourse.cmake.org
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] crosscompilation and source generation via add_custom_command

[Jędrzej Dudkiewicz]

Hello,

I cross-compile a project from x86_64-linux-gnu to
arm-linux-gnueabihf. Currently this is done using hand-written
Makefiles, but I"m moving it to cmake. This project uses custom
version of `lemon` parser generator. Aforementioned lemon is included
as a source - this is single .c file that is compiled during build. Is
there a way to build and run this binary on x86_64-linux-gnu while
cross-compiling to arm-linux-gnuabihf? I suppose I could
add_custom_command that would compile using hardcoded compiler
version, but it doesn't seem very nice.

Thanks in advance,
-- 
Jędrzej Dudkiewicz

I really hate this damn machine, I wish that they would sell it.
It never does just what I want, but only what I tell it.
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] cross-compiling final linker transitive lib not found

[De Pauw jimmy]

Hello,

I have a problem with cross-compiling that i don't know how to solve 
even after days of searching.

The situation is :

- Project compiled on ARM platform directly, works fine.
- Cross-compiled, final executable linking fails because of a transitive 
library not found.


I am using a few system libraries that are all found in the initial 
cmake setup.

Compiling also works until it requires linking of my final target.

There, at some point, it checks for 
/usr/local/sysroot_jetson/usr/lib/aarch64-linux-gnu/libdrm.so.2 (which 
is found)
libdrm depends on libnvll.so wich the linker does not found even though 
it's available on my sysroot but not in a standard directory.

The directory is /usr/local/sysroot_jetson/usr/lib/aarch64-linux-gnu/tegra

On the ARM system this directory is searched by the linker because of 
/etc/ld.so.conf.d/cuda-10-0.conf but this is not used at all when 
cross-compiling.


How the linker when cross-compiling can be instructed to search in 
additional directories for transitive dependencies?


--

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] Installing targets from a monorepository

[A . Dmitrovsky]

Hi, What is the recommended way of handling installation of targets in a monorepository? We've got a fairly large project with many targets. Some of the targets are libraries used by other targets, some are final executables. Different executables depend on different libraries. So far we only support configuring project from top-level CMakeLists. I am looking for a best way to build a target + its dependencies and install only built files (for simplicity, we don't care about other binaries like 3rd party SDKs at this point). What I expect to receive is CMAKE_BUILD_PREFIX dir with a binary and all of its dependencies that I use for packaging/deployment. So far I am aware of several approaches, the simplest is to use install(...OPTIONAL...) commands along with CMAKE_SKIP_INSTALL_ALL_DEPENDENCY.However, this approach looks to me a little hackerish. Since monorepos are quite popular these days, is there a better approach to do what I am trying?-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] [ANNOUNCE] CMake 3.16.3 available for download

[Robert Maynard via CMake]

We are pleased to announce that CMake 3.16.3 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.16.3 since 3.16.2:

Ashley Whetter (1):
  FindOpenSSL: Fix ordering of dependency link flags

Brad King (3):
  GNUtoMS: Add search path for VS 2019 environment scripts
  IRSL: Install msvcp140_{1,2,codecvt_ids}.dll if available
  CMake 3.16.3

Cristian Adam (4):
  ObjC: Add _COMPILE_LAUNCHER support
  ObjC: Add VISIBLITY_INLINES_HIDDEN support
  Unity Build: include language in generated source file name
  PCH: No repeated path for internal generated PCH files (MSVC case)

Kyle Edwards (2):
  CTest: Improve error handling when reading resource spec file
  CPack: Fix regression in DEB generator description

Marc Chevrier (3):
  FindPython*: Fix erroneous target properties setting
  macOS: Add support for new Xcode 11 frameworks directory
  FindPython: ensure new Xcode framework for Python3 is detected

Miro Hrončok (1):
  FindPython: Add support for version 3.9

Neil Carlson (1):
  Fortran: Add support for NAG Fortran submodules

Pavel Liavonau (1):
  VS: Add Fortran link flag table entries for /OPT:*

Robert Maynard (1):
  CUDA: Do not device link if target has no CUDA usage

Sebastian Holtermann (1):
  Autogen: Enable SKIP_UNITY_BUILD_INCLUSION on AUTORCC generated files

Silvio Traversaro (2):
  FindMatlab: add R2019a and R2019b MATLAB_VERSIONS_MAPPING
  FindMatlab: in matlab_add_mex use the correct version file
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] [ANNOUNCE] CMake Discourse forum now available

[Robert Maynard via CMake]

A reminder that CMake is transitioning to Discouse, and by the end of
March 2020 the mailing lists will be read-only, and the archives
will remain available after that.

The Discourse forum for the CMake community is:

  https://discourse.cmake.org

Discourse offers users more control over their level of participation,
allowing them to subscribe or unsubscribe by category or individual topic.
Users may choose to participate by web forum, email, or both.

To get started, see our Forum Help page:

  https://discourse.cmake.org/faq

User accounts may be created using Email Registration, a GitHub Account, or a
Google Account.

For those who prefer email over web forums, the Forum Help page includes
instructions to participate in the forum purely via email.  Creating topics in
the forum via email (and receiving replies) is supported *with or without*
registering a user account.  User accounts may be configured to receive email
notifications for forum activity at several levels of granularity, or to
receive email notifications for all activity like a mailing list.

On Tue, Nov 5, 2019 at 12:13 PM Robert Maynard
 wrote:
>
> A Discourse forum is now available for the CMake community:
>
>   https://discourse.cmake.org
>
> Discourse offers users more control over their level of participation,
> allowing them to subscribe or unsubscribe by category or individual topic.
> Users may choose to participate by web forum, email, or both.
>
> To get started, see our Forum Help page:
>
>   https://discourse.cmake.org/faq
>
> User accounts may be created using Email Registration, a GitHub Account, or a
> Google Account.
>
> For those who prefer email over web forums, the Forum Help page includes
> instructions to participate in the forum purely via email.  Creating topics in
> the forum via email (and receiving replies) is supported *with or without*
> registering a user account.  User accounts may be configured to receive email
> notifications for forum activity at several levels of granularity, or to
> receive email notifications for all activity like a mailing list.
>
> To facilitate a transition period, the current mailman-based mailing lists
> will remain active until at least the end of March 2020, and their archives
> will remain available after that.
>
> See you on discourse.cmake.org!
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] Problems with installer on macOS

[Roman Wüger]

Setting BundleIsRelocatable to false was the solution

Best regards 
Roman

> Am 08.01.2020 um 21:07 schrieb Roman Wüger :
> 
> Hello,
> 
> I generate a productbuild installer with CPack.
> 
> When I start the installer and view the files then everthing is packaged as 
> it should. But when I install them, then not all files are installed.
> 
> The install protocol from the installer succeeds with no errors.
> 
> Any hints?
> 
> Best Regards
> Roman
> -- 
> 
> Powered by kitware.com/cmake
> 
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit https://cmake.org/services
> 
> Visit other Kitware open-source projects at https://www.kitware.com/platforms
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
> 
> This mailing list is deprecated in favor of https://discourse.cmake.org
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] Problems with installer on macOS

[Roman Wüger]

Hello,

I generate a productbuild installer with CPack.

When I start the installer and view the files then everthing is packaged as it 
should. But when I install them, then not all files are installed.

The install protocol from the installer succeeds with no errors.

Any hints?

Best Regards
Roman
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] [cmake-developers] productbuild: Installing to absolute system path or to user home path

[Roman Wüger]

Ok if someone is interested I solved it with a post-install script at the 
moment. I installed it in the default location and moved it afterwards with the 
post-install script to the ~/Library...

Regards
Roman

> Am 05.11.2019 um 15:02 schrieb Roman Wüger :
> 
> 
> Hello,
> 
> The main wish is to install to the user directory as described in the 
> documentation, the absolute path to the „all users“ works already:
> 
> Here is the description from the manual, also attached as an image
> 
> Automatic plug-in loading
> Lightroom automatically checks for plug-ins in the standard Modules folder 
> where other Lightroom settings are stored:
>In Mac OS (current user) In Mac OS (all users)
> In Windows XP
> plug-in and also installs a helper application.
> Plug-ins that are installed in this location are automatically listed in the 
> Plug-in Manager dialog. You can use the dialog to enable or disable such a 
> plug-in, but not to remove it. The Remove button is dimmed when such a 
> plug-in is selected.
> ~/Library/Application Support/Adobe/Lightroom/Modules /Library/Application 
> Support/Adobe/Lightroom/Modules
> C:\Documents and Users\username\Application Data\Adobe\Lightroom\Modules
> C:\Users\username\AppData\Roaming\Adobe\Lightroom\Modules You may want to use 
> this location if, for example, you are writing an installer that installs a 
> Lightroom
>In Windows 7/Vista
> 
> 
> 
> 
> Regards
> Roman
> 
>>> Am 01.11.2019 um 05:10 schrieb David Aguilar :
>>> 
>> 
>> I would also suggest avoiding absolute paths so that the user can tell you 
>> where to root the installation.
>> 
>> One way to do that is to use GNUInstallDirs so that the user can specify the 
>> install prefix.  And maybe you want to let them user their home directory be 
>> default if they've not specified it:
>> 
>> 
>> include(GNUInstallDirs)
>> 
>> if (CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
>> # NOTE: default to the home directory, assumes $HOME is defined in the 
>> environment
>> set(CMAKE_INSTALL_PREFIX $ENV{HOME} CACHE PATH "Installation prefix" 
>> FORCE) 
>> endif ()
>> 
>> [... usual stuff here ...]
>> 
>> # NOTE: relative path
>> install(TARGETS target_name DESTINATION "Library/Application 
>> Support/Adobe/Lightroom/Modules")
>> 
>> 
>> Then the user would just "make && make install" and it'll install to their 
>> ~/Library directory by default.
>> 
>> Then, if they have the permissions to do so, they can install to the global 
>> system location using:
>> 
>> cmake -D CMAKE_INSTALL_PREFIX=/ . &&
>> make &&
>> sudo make install
>> 
>> Mixing both in the same cmake invocation can be done, but now you've made it 
>> impossible to install into other locations (for testing, packaging, etc).
>> 
>> For example, someone might want to package it without sudo, so they might 
>> want to do this instead of "sudo make install":
>> 
>> make DESTDIR=$PWD/tmp install
>> 
>> and then you have a tmp/Library/ directory structure that can be made into a 
>> macOS .pkg installer:
>> 
>> pkgbuild --install-location / --identifier org.domain.pkgs.example 
>> --version 1.0.0 --root tmp example-1.0.0.pkg
>> 
>> And now you have a .pkg installer that updates the global /Library directory 
>> without needing to be root to build it.
>> 
>> 
>> Question -- is this a situation where you want a single build to install 
>> into both locations, or is the literally the same plugin and it only needs 
>> to be in one of the two locations (global vs. user)?  I interpreted your 
>> question to be about the latter, where the user really only needs one or the 
>> other, and it's the same plugin in both cases.
>> 
>> I don't know if cpack handles this for you, but hopefully this is helpful 
>> advice.
>> 
>> 
>>> On Thu, Oct 31, 2019 at 10:19 AM David Cole via cmake-developers 
>>>  wrote:
>>> According to the docs, the INSTALL command uses the absolute path if
>>> it is given as the DESTINATION, so  it should work.
>>> https://cmake.org/cmake/help/latest/command/install.html
>>> 
>>> Did you try using a double quoted string, instead of escaping the
>>> space with a backslash?
>>> 
>>> I think this should work for the absolute one:
>>> INSTALL( ... DESTINATION "/abs/path/to/some folder")
>>> 
>>> For the one in the home directory, I'm not sure if a string that
>>> starts with "~" is considered absolute or not, so it may or may not
>>> end up where you expect it. Can you resolve it before hand with a
>>> get_filename_component call, (or otherwise), and pass in a string that
>>> begins with "/" ...?
>>> 
>>> 
>>> Hope this helps,
>>> David C.
>>> 
>>> 
>>> On Mon, Oct 28, 2019 at 4:36 PM Roman Wüger  wrote:
>>> > Hello,
>>> > I tried to install a file/directory with productbuild on macOS which is 
>>> > generated with CPack
>>> > The most of the files are installed correctly, but I have two problems:
>>> >
>>> > If I want to install to “/Library/Application\ 
>>> > Support/Adobe/Lightroom/Modules”
>>> > If I want to install to the 

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

[Alan W. Irwin]

On 2019-12-29 12:15+1100 Craig Scott wrote:


This one has sat in my inbox for a long time - sorry I'm only getting to it
now!


No problem, and big thanks for replying late rather than taking the
easier course of replying never.  I haven't yet absorbed all of what
you said, but I am sure your answers will be a big help to my project
to modernize the CMake-base build system for PLplot which was
originally "designed" in 2006 by a team of CMake newbies (including
me).

Alan
__
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] Difference between PRIVATE and PUBLIC with target_link_libraries

[Craig Scott]

This one has sat in my inbox for a long time - sorry I'm only getting to it
now!

On Wed, Sep 18, 2019 at 9:21 AM Alan W. Irwin 
wrote:

> Hi Craig:
>
> It appears you pretty much made the definitive statement about
> target_link_libraries (TLL)  options at
> .  However,
> I have some further questions about this key section of your
> statement:
>
> "[...] when A links in B as PRIVATE, the include directories of B
> never propagate to something linking to A, but if A is a static
> library, then the *linking* of B behaves as though the relationship
> was PUBLIC. This PRIVATE-becomes-PUBLIC behaviour for static libraries
> only applies to the *linking*, not to the other dependencies (compiler
> options/flags and include search paths). The upshot of all this is
> that if you select PRIVATE, PUBLIC or INTERFACE based on the
> explanations in the dot points above, then CMake will ensure
> dependencies propagate through to where they are required, regardless
> of whether libraries are static or shared. This does, of course, rely
> on you the developer not missing any dependencies or specifying the
> wrong PRIVATE/PUBLIC/INTERFACE relationship."
>
> The issues I am concerned with are the following:
>
> * The target_include_directories, target_compile_definitions, and
>target_compile_options (TID, TCD, and TCO) commands all have
> options.  I am pretty sure those options
>must take precedence over the TLL  options,
>but can you confirm that?
>

No that's not a correct interpretation. For target_include_directories(),
target_compile_definitions() and target_compile_options(), a PRIVATE item
only applies to that target, meaning it only affects how that target is
built. An INTERFACE item would affect how some other target that links to
that target is built. This is true even if that other target does a PRIVATE
link to this target.

The PRIVATE/INTERFACE/PUBLIC specification in target_link_libraries() is
somewhat like a next layer out. Let me try to explain via an example. Let's
say we have three libraries: inner, middle and outer, where outer links to
middle and middle links to inner. The outer library doesn't reference
anything from the inner library directly. We would express it something
like this:

target_compile_definitions(inner PUBLIC SomeSetting=true)   # Used in
discussion below
target_link_libraries(middle  inner)
target_link_libraries(outer PRIVATE middle)


The inner library defines the SomeSetting=true definition as PUBLIC, so
both inner and middle will have this definition applied to them.

   - If  is PRIVATE, the middle library links to inner as PRIVATE, so
   the SomeSetting=true definition remains hidden from the outer library.
   - If  is PUBLIC, the middle library links to inner as PUBLIC, so the
   SomeSetting=true definition is applied transitively to anything that
   links to middle. That means that outer will now have the SomeSetting=true
definition applied to it as well.

I recommend you play around with variations of the above example and see
the command lines that are generated. It is probably the most effective way
to solidify one's understanding and answer questions about how the
relationships work. For your convenience, here's a complete working example
that you can start with:

cmake_minimum_required(VERSION 3.16)
project(pubpriv)

add_library(inner inner.cpp)
add_library(middle middle.cpp)
add_library(outer outer.cpp)

target_compile_definitions(inner PUBLIC SomeSetting=true)
target_compile_definitions(middle PRIVATE OtherSetting=true)

target_link_libraries(middle PUBLIC inner)
target_link_libraries(outer PRIVATE middle)





>
> * It appears to me that if a CMake-based build system is configured
>properly there is very little need for the PUBLIC option for TLL
>because PRIVATE works well for shared libraries and the
>PRIVATE-becomes-PUBLIC behaviour for static libraries you mentioned
>above.  Can you confirm this statement is generally true both for
>Unix and Windows?
>

Continuing with the example I used above, if the public headers of the
middle library refer to anything from the inner library, then
target_link_libraries() should specify PUBLIC, regardless of whether middle
or inner are static or shared libraries. Simon's reply already highlighted
cases involving inlined functions where this is important. The platform is
not relevant here, the same behavior applies to all platforms.




>
> I am concerned with the above issues because the PLplot build system
> currently does the following:
>
> * For shared libraries uses the PRIVATE TLL option for the Unix case
>and PUBLIC TLL option for the Windows case.
>

I don't understand the rationale for this. Perhaps it is related to Visual
Studio making symbols hidden by default, but Clang and GCC making symbols
visible by default (see my CppCon 2019 talk

Re: [CMake] Providing multiple different MAJOR API versions with write_basic_package_version_file

[Craig Scott]

On Mon, Nov 4, 2019 at 10:54 PM Philip Van Hoof 
wrote:

> Hello,
>
> After Craig's very interesting presentation at CppCon 2019* I learned a
> bunch of new things which I of course immediately wanted to try out**.
>
> I read about the write_basic_package_version_file which is in
> CMakePackageConfigHelpers. Craig also mentioned in the presentation
> that you can have a so called API-version in the target's name. And
> that for example Qt does this (Qt5Core, which has the MAJOR number 5 in
> its target name).
>
> For my target name I prefer to have the API version after a dash, like
> how GLib and DBus packages do it: libglib-2.0.so.0.6200.1 on current
> Ubuntu, for example in /usr/lib/x86_64-linux-gnu.
>

Understand that from CMake's point of view, the library name is then
glib-2.0 and the fact that it contains numbers that look like a version of
some kind is completely irrelevant (to CMake). You could just as well have
called it glib-specialsauce. Putting an API version into the library name
is *changing* the library name to something else. This is particularly
inconvenient for projects using find_package() to find your library, since
they have to specify the exact API version now because you've included it
in the library name. glib-2.0 is a completely different library to glib-2.1,
for example. It might be more precise, but it is less convenient to
consume. You could potentially remove that inconvenience by naming the
config package file glibConfig.cmake instead of glib-2.0Config.cmake, then
place it under an API-versioned directory that find_package() would search
in, but that would seem to remove the very advantage you are trying to gain
by putting the API version in the library name. The consuming project would
effectively be able to ignore the API version if you did this.



>
> I wonder what that means for the  property of
> write_basic_package_version_file. In the autotools and meson world, the
> usage of pkg-config files seems to indicate that the same filename
> naming scheme applies to the .pc file:
>
> /usr/lib/x86_64-linux-gnu/pkgconfig/glib-2.0.pc
>
> This allows me to distinguish between older MAJOR API versions of GLib
> and newer MAJOR API versions of it, using FindPkgConfig***
>
> Supposedly something similar is possible with find_package's .cmake
> files as installed by write_basic_package_version_file?
>

As above, you are creating an entirely different library by putting the API
version in its base name. So your call to find_package() would be looking
for that API-specific name and your package version file would have to
match that expected name too.


>
> How do I provide a PackageNameConfigVersion.cmake for major version 1.0
> and 2.0 (the equivalent of PackageName-1.0.pc and PackageName-2.0.pc in
> the pkgconfig directory)?
>

Since from CMake's perspective they are two completely different libraries,
you'd end up with PackageName-1.0ConfigVersion.cmake and
PackageName-2.0ConfigVersion.cmake as the file names.



>
> Kind regards,
>
> Philip
>
> * https://www.youtube.com/watch?v=m0DwB4OvDXk
> **
> https://github.com/pvanhoof/dir-examples/commit/523cab5edaff99acba037218d5b95227cb2487a9
> *** https://cmake.org/cmake/help/v3.15/module/FindPkgConfig.html



I've debated whether to express my own opinion on this, but in this case
I'll risk it. I personally find that putting an API version in the name of
the library itself to be an annoyance. I'm typically interested in the ABI
versioning, and I take on the responsibility of understanding how that maps
to the API. If semantic versioning is being followed for the ABI
versioning, then this mapping is typically trivial. To me, any gains from
making the API version explicit in the library name are less significant
than the negative impact on the ease of consuming that library and the
added "scare factor" of an overly complicated versioning system. Versioning
is already complex enough for most users, if we can avoid making it more
so, then users will likely appreciate that.

It may be instructive to note that there were changes in CMake 3.14 to
support Qt being found without the API version being specified as part of
the package name (i.e. as find_package(Qt)). See policy CMP0084
 for some brief
background.

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide 
Consulting services (CMake, C++, build/release processes):
https://crascit.com/services
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] Qt translation handling

[angroyer]

Another thing:

in case you don't want to re-generate the .ts files every time, you could
comment out:
file(GLOB_RECURSE TS_SOURCES "*.cpp" "*.h" "*.ui")
qt5_create_translation(QM_FILES ${TS_FILES} ${TS_SOURCES})

and use instead the following line with the .ts files already committed in
your project:
qt5_add_translation(QM_FILES ${TS_FILES})

Cordialement
Anthony




--
Sent from: http://cmake.3232098.n2.nabble.com/
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] Qt translation handling

[angroyer]

Bonjour Francis,

thank you for sharing this snippet.

I have read thoroughly your example and tried it but it seems to me that
this snippet is similar to the qt5_create_translation() function.

First of all, with cmake >= 3.0.0 and AUTORCC set to ON, adding
${CMAKE_CURRENT_BINARY_DIR}/translations.qrc in add_executable() make the
executable depends on the translations.qrc and make also translations.qrc
depends on the files listed in the translations.qrc. So everytime a .qm
listed in translations.qrc changes, the qrc_translations.cpp is created and
compiled. So, it is not necessary to add ${QM_FILES} in the add_executable()
statement.

So, with your piece of code:
 * ${CMAKE_CURRENT_BINARY_DIR}/translations.qrc in add_executable make App
depend on the qrc_translations.qrc and qrc_translations.qrc depend on files
listed in qrc_translations.qrc
 * each .qm file is dependent on a .ts file: statement qt5_add_translation()
 * each .ts file is dependent on ${TS_SOURCES}: statement
add_custom_command()

So everytime a file listed in ${TS_SOURCES} changes, the .ts is rebuilt, the
.qm is rebuilt and the qrc_translations.cpp is compiled. You could have
obtained the same thing with:

set(TS_FILES
${CMAKE_CURRENT_SOURCE_DIR}/translations/app_fr.ts
)
file(GLOB_RECURSE TS_SOURCES "*.cpp" "*.h" "*.ui")
qt5_create_translation(QM_FILES ${TS_FILES} ${TS_SOURCES})

configure_file(translations.qrc ${CMAKE_CURRENT_BINARY_DIR} COPYONLY)
add_executable(App
${CMAKE_CURRENT_BINARY_DIR}/translations.qrc
)

and translations.qrc containing:


gui_fr.qm



I have tested with cmake 3.16.1.

It is worth mentioning that the Qt documentation:
https://doc.qt.io/qt-5/qtlinguist-cmake-qt5-create-translation.html
indicates:
qt5_create_translation(QM_FILES ${CMAKE_SOURCE_DIR} helloworld_en.ts
helloworld_de.ts)
without passing the list of source/headers files. So the .ts files are
reconstructed when the date of the source folder changes but not for the
date of the subdirectories. The date of the source folder changes when some
files are created/removed/modified in the directory but not for the files in
subdirectories.

This could leads to errors since the .ts files would not be rebuilt when a
file in a subdirectory change. So changing from branch to branch might
change the date of the source folder and regenerates the .ts files.

What do you think ?

In case you want to keep the .qm files in your source folder, you could
indicate to the cmake rule where to generate the .qm file with the
OUTPUT_LOCATION:
set_source_files_properties(${TS_FILES} PROPERTIES OUTPUT_LOCATION
${CMAKE_SOURCE_DIR}/translations)
See https://doc.qt.io/qt-5/qtlinguist-cmake-qt5-add-translation.html
It works also for qt5_create_translation() that calls in turn the
qt5_add_translation().

And so you do not need to copy the translations.qrc to the build folder. The
code becomes:

set(TS_FILES
${CMAKE_CURRENT_SOURCE_DIR}/translations/app_fr.ts
)
set_source_files_properties(${TS_FILES} PROPERTIES OUTPUT_LOCATION
${CMAKE_CURRENT_SOURCE_DIR}/translations)
file(GLOB_RECURSE TS_SOURCES "*.cpp" "*.h" "*.ui")
qt5_create_translation(QM_FILES ${TS_FILES} ${TS_SOURCES})

add_executable(App
translations/translations.qrc
)

and translations/translations.qrc containing:


gui_fr.qm



Cordialement,
Anthony




--
Sent from: http://cmake.3232098.n2.nabble.com/
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] msys2-mingw64 cmake gives undefined behaviour, can not find include header

[Stéphane Ancelot]

Hi,

Migrating a code to msys2 compilation (cmake inside msys ), it does not 
find an include file for unknwon reason.



the file is located in a project defined as follow:

cmake_minimum_required(VERSION 3.10)
project(include_commun)

add_library(include_commun INTERFACE)
target_include_directories(include_commun INTERFACE   .)


and the project causing error :

cmake_minimum_required(VERSION 3.10)
project(import_export_unix)

add_library(import_export_unix STATIC import_export_unix.h 
import_export_unix.cpp)
set_target_properties(import_export_unix PROPERTIES 
POSITION_INDEPENDENT_CODE TRUE)

target_include_directories(import_export_unix PUBLIC .)
target_link_libraries(import_export_unix PRIVATE include_machine 
include_commun)



error displayed :

[  3%] Building CXX object 
IMPORT_EXPORT_UNIX/CMakeFiles/import_export_unix.dir/import_export_unix.cpp.obj
cd /e/WORKSPACE/BASE_SILFAX_SAFETY/build/IMPORT_EXPORT_UNIX && 
/mingw64/bin/c++.exe 
@CMakeFiles/import_export_unix.dir/includes_CXX.rsp  -o 
CMakeFiles/import_export_unix.dir/import_export_unix.cpp.obj -c 
/e/WORKSPACE/BASE_SILFAX_SAFETY/IMPORT_EXPORT_UNIX/import_export_unix.cpp
E:/WORKSPACE/BASE_SILFAX_SAFETY/IMPORT_EXPORT_UNIX/import_export_unix.cpp:19:10: 
fatal error: defprog.h: No such file or directory


CMakeFiles/import_export_unix.dir/includes_CXX.rsp content :

-I/e/WORKSPACE/BASE_SILFAX_SAFETY/IMPORT_EXPORT_UNIX/. 
-I/e/WORKSPACE/BASE_SILFAX_SAFETY/INCLUDE_MACHINE/. 
-I/e/WORKSPACE/BASE_SILFAX_SAFETY/INCLUDE_COMMUN/.



Regards,

Steph


-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] [ANNOUNCE] CMake 3.16.2 available for download

[Robert Maynard via CMake]

We are pleased to announce that CMake 3.16.2 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.16.2 since 3.16.1:

Brad King (6):
  VS: Fix support for v142 toolset minor versions in VS 16.5+
  FindBLAS: Consider OpenBLAS with thread libraries only with C or CXX
  FindBoost: Add support for Boost 1.72
  Autogen: Revert processing of .hh files for compatibility
  FindLAPACK: Fix support for LAPACK symbols inside BLAS libraries
  CMake 3.16.2

Cristian Adam (1):
  PCH: Append pch header file to list of forced include files

Michael Dickens (1):
  Tests: Fix testCTestResourceSpec struct initialization for some compilers
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] Suppress a specific path in the RPATH of an executable explicitly

[Eric Dönges]

On 19.12.19 10:52, Cornelis Bockemühl wrote:
> In a project setup I am copying a number of shared library files into
> the executable directory (basically with a mechanism involving
> configure_file - because the "install" logic was simply too complicated
> for the project and for my limited brain capacity!).
> 
> On a Windows system this works nicely, but on a Linux system there is
> always some logic that puts the original shared library location into
> the executable's RUNPATH, with the effect that they are not found in the
> place where they are supposed to be found.
> 
> I tried to avoid this by using
> 
> set_target_properties(
>     
>     PROPERTIES
>     CMAKE_SKIP_RPATH TRUE)

This cannot work because CMAKE_SKIP_RPATH is a variable, not a property.
Variables are set with the set() command (or from the command line with
the -D option), and often serve as the default values for a specific
property if that property isn't explicitly set. Properties are set with
set_property() or set_target_properties() and apply only to the specific
target they are set for. In general, anything with a 'CMAKE_' prefix is
a variable, not a property.

Note that CMake distinguishes between "build time" and "install time"
rpath, allowing you to have different rpaths for the binaries in your
build and install directories. So if you do not want any rpath
information added to your binaries, you would

set(CMAKE_SKIP_RPATH TRUE)
set(CMAKE_SKIP_INSTALL_RPATH TRUE)

before defining any targets.

If you want to control the rpath for individual binaries, you would set
the appropriate properties for the binary target(s) whose rpath you want
to set. Check the CMake documentation for properties containing 'RPATH'
to see which properties are available - there is quite a number of them.
As far as I know, these properties are not transitive, so you cannot set
the rpath for a shared library and expect targets linked against that
library to receive this rpath.

It sounds to me that what you probably want to do is set the RPATH of
your executables to look in $ORIGIN and nowhere else. One way to do this
would be to

set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
set(CMAKE_INSTALL_RPATH "$ORIGIN")

before defining your targets. If you want control over individual
targets, you would set the BUILD_WITH_INSTALL_RPATH and INSTALL_RPATH
properties on the individual targets.

For more details, see
https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling.

-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] Suppress a specific path in the RPATH of an executable explicitly

[Cornelis Bockemühl]

In a project setup I am copying a number of shared library files into the 
executable directory (basically with a mechanism involving configure_file - 
because the "install" logic was simply too complicated for the project and for 
my limited brain capacity!).

On a Windows system this works nicely, but on a Linux system there is always 
some logic that puts the original shared library location into the executable's 
RUNPATH, with the effect that they are not found in the place where they are 
supposed to be found.

I tried to avoid this by using
set_target_properties(
    
    PROPERTIES
    CMAKE_SKIP_RPATH TRUE)However, any effect was not visible: the "old" 
path is still included in RUNPATH. Maybe I overlooked one more imported target, 
overriding the effect of above, or it does not work on imported targets at all. 
Anyway, it would be much easier if I could simply drop one specific path 
explicitly with some setting! Dropping all is again too much - because I need 
other entries for other libraries.

Is there such an option available?

Maybe a workaround would be to explicitly prepend "$ORIGIN" to the RUNPATH in 
the executable: In this way the shared libs would be found in the executable 
directory first and any other "wrong" paths would not hurt.

Many thanks and regards,
Cornelis Bockemühl
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] CMake's FindBoost Module Can't Detect Boost Version

[Deniz Bahadir]

Am 17.12.19 um 17:35 schrieb Mateusz Loskot:

On Tue, 17 Dec 2019 at 16:39, Osman Zakir  wrote:


I built Boost 1.72.0 while passing the "--layout=versioned" flag to b2, but 
when I tried to rebuild Jinja2Cpp with the newer version of Boost using CMake, it failed 
to generate project files and said it couldn't filesystem and system and also couldn't 
detect version information.  Could someone please help me out with this?


I recall you have been asking similar questions in the past about Jinja2Cpp.

You have received number of useful suggestions [1], e.g. to use
-DBoost_DEBUG=ON,
and investigate detailed diagnostics, to try -DBoost_COMPILER=...
and -DBoost_ARCHITECTURE hints, etc.
Please, apply this knowledge.

Finally, your questions are poorly formulated e.g. my crystal sphere has broken
and I can't figure out what compiler, toolset, cmake version, etc. you are on.
Next time, try to help people help you [2]

[1] https://cmake.org/pipermail/cmake/2018-October/068477.html
[2] http://www.catb.org/~esr/faqs/smart-questions.html

Best regards,



Osman,

as you are obviously trying to to find a pretty recent Boost version 
(1.72.0) that you even built yourself, you could probably try to skip 
the Module-mode of the `find_package(Boost ...)` call and instead try to 
use the Config-mode directly, like this:

```
find_package(Boost 1.72.0 EXACT CONFIG ...)
```

Thereby, you are skipping CMake's FindBoost module entirely and instead 
rely on the BoostConfig.cmake file provided by Boost itself. (Then you 
can even skip defining the `Boost_ADDITIONAL_VERSIONS` variable.)
However, if you did not install your Boost version in one of the 
default-locations you probably need to provide some HINTs or PATHs to 
`find_package`.

See [3] for further information.

Nevertheless, if you have a pretty recent version of CMake with a pretty 
recent version of its FindBoost module, then even in Module mode the 
FindBoost module will first try to find BoostConfig.cmake.



[3] 
https://cmake.org/cmake/help/latest/command/find_package.html#full-signature-and-config-mode



Best regards,
Deniz

PS: This mailing-list will probably be discontinued within the next few 
weeks. For future questions you should probably switch to 
https://discourse.cmake.org, as that is the successor of the CMake 
mailing-lists.

--

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] CMake's FindBoost Module Can't Detect Boost Version

[Osman Zakir]

Yeah, forgot.

I did specify the values for the flags on the actual thing.  
-DBoost_COMPILER=-vc142, -DBoost_ARCHITECTURE=-x64 and -DBoost_DEBUG=ON.  I'll 
try specifying the version number like what you said.  Thanks for that.
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] CMake's FindBoost Module Can't Detect Boost Version

[Mateusz Loskot]

On Tue, 17 Dec 2019 at 18:43, Osman Zakir  wrote:
>
> I tried passing -DBoost_COMPILER and -DBoost_DEBUG

That is incorrect!

The options must read  -DBoost_DEBUG=ON
and -DBoost_COMPILER=-vc141 or vc142, depending on
what b2.exe generated in names for your MSVC version.

> but it seems it's only looking for up to Boost 1.71.0; the test versions go 
> up to there only.
> Should I edit the FindBoost.cmake file to have it look for version 1.72.0 as 
> well?

If you have read/searched the FindBoost docs page
https://cmake.org/cmake/help/latest/module/FindBoost.html?highlight=version
you would have learned that you can specify
-DBoost_ADDITIONAL_VERSIONS=1.72

> I don't know about all of the flags I need to pass, but if it can find the 
> Boost version then it should be able to detect all of the stuff on its own, 
> right?

It should, but it still may need hints like Boost_COMPILER, or
Boost_ARCHITECTURE.

FindBoost is a Find-module.
A Find-module is a ***guesser***.
A guesser has right to fail to guess...no hard promises.

https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html

"Unlike a package configuration file, it is not shipped with upstream,
but is used by downstream to find the files by guessing locations of
files with platform-specific hints."

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] CMake's FindBoost Module Can't Detect Boost Version

[Osman Zakir]

I tried passing -DBoost_COMPILER and -DBoost_DEBUG but it seems it's only 
looking for up to Boost 1.71.0; the test versions go up to there only.  Should 
I edit the FindBoost.cmake file to have it look for version 1.72.0 as well?

I'm using MSVC version 14.2, Visual Studio 2019.  I'm using the Developer 
Command Prompt for VS2019.

I don't know about all of the flags I need to pass, but if it can find the 
Boost version then it should be able to detect all of the stuff on its own, 
right?  The first step there isn't going right.
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] CMake's FindBoost Module Can't Detect Boost Version

[Mateusz Loskot]

On Tue, 17 Dec 2019 at 16:39, Osman Zakir  wrote:
>
> I built Boost 1.72.0 while passing the "--layout=versioned" flag to b2, but 
> when I tried to rebuild Jinja2Cpp with the newer version of Boost using 
> CMake, it failed to generate project files and said it couldn't filesystem 
> and system and also couldn't detect version information.  Could someone 
> please help me out with this?

I recall you have been asking similar questions in the past about Jinja2Cpp.

You have received number of useful suggestions [1], e.g. to use
-DBoost_DEBUG=ON,
and investigate detailed diagnostics, to try -DBoost_COMPILER=...
and -DBoost_ARCHITECTURE hints, etc.
Please, apply this knowledge.

Finally, your questions are poorly formulated e.g. my crystal sphere has broken
and I can't figure out what compiler, toolset, cmake version, etc. you are on.
Next time, try to help people help you [2]

[1] https://cmake.org/pipermail/cmake/2018-October/068477.html
[2] http://www.catb.org/~esr/faqs/smart-questions.html

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] CMake's FindBoost Module Can't Detect Boost Version

[Osman Zakir]

I built Boost 1.72.0 while passing the "--layout=versioned" flag to b2, but 
when I tried to rebuild Jinja2Cpp with the newer version of Boost using CMake, 
it failed to generate project files and said it couldn't filesystem and system 
and also couldn't detect version information.  Could someone please help me out 
with this?  Thanks.
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] [ANNOUNCE] CMake 3.15.6 available for download

[Robert Maynard via CMake]

We are pleased to announce that CMake 3.15.6 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.15.6 since 3.15.5:

Alexander Grund (1):
  Check for support before adding bigtoc linker flag

Ben Boeckel (1):
  FindPostgreSQL: support version encoding used in pre-10 releases

Brad King (4):
  CMakeParseImplicitIncludeInfo: Remove all CR chars from compiler output
  VS: Fix support for v142 toolset minor versions in VS 16.5+
  FindBLAS: Consider OpenBLAS with thread libraries only with C or CXX
  CMake 3.15.6

Deniz Bahadir (1):
  FindBoost: Prevent warning due to new meta-component "ALL" of Boost 1.73

Markus Mittendrein (1):
  FindGTK2: Add harfbuzz to GTK2_INCLUDE_DIRS
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] (no subject)

[baschdel_98]

Hello,

 

I've got a small Problem with Cpack and BundleUtilities on Windows.

At the moment I want to copy *.dll file at install time and also include these in the created "installer".

When I install the program through VisualStudio, everything works like a charm. But when I invoke cpack via the command prompt, no dll files appear in the "Installer". I am not sure what is happening.

 

My code to archive this looks like this:


set(RELATIV_INSTALL_DIRECTORY "bin")
install(TARGETS ${CMAKE_PROJECT_NAME} 
    RUNTIME DESTINATION ${RELATIV_INSTALL_DIRECTORY}
    COMPONENT app)



if(WIN32)
    #set Variable "dirs"

    set(executable_path "\${CMAKE_INSTALL_PREFIX}/${RELATIV_INSTALL_DIRECTORY}/${CMAKE_PROJECT_NAME}.exe")
endif()




install(CODE "
    include (BundleUtilities)
    fixup_bundle(\"${executable_path}\" \"\" \"${DIRS}\")
    "
    COMPONENT app
    )

set(CPACK_OUTPUT_FILE_PREFIX "${CMAKE_BINARY_DIR}/package")

set(CPACK_PACKAGE_NAME "${CMAKE_PROJECT_NAME}")
set(CPACK_PACKAGE_VENDOR "${COMPANY_NAME}")
set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "Installer for ${CMAKE_PROJECT_NAME}.")
set(CPACK_PACKAGE_VERSION_MAJOR "${PROJECT_VERSION_MAJOR}")
set(CPACK_PACKAGE_VERSION_MINOR "${PROJECT_VERSION_MINOR}")
set(CPACK_PACKAGE_VERSION_PATCH "${PROJECT_VERSION_PATCH}")
set(CPACK_PACKAGE_VERSION "${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}")
set(CPACK_PACKAGE_INSTALL_DIRECTORY "company/${CMAKE_PROJECT_NAME}")

set(CPACK_COMPONENTS_ALL app)

set(CPACK_RESOURCE_FILE_LICENSE "${CMAKE_SOURCE_DIR}/license.txt")


if(WIN32)
    set(CPACK_GENERATOR WIX;7Z)
endif()

include(CPack)

 

I hope someone is able to help me with this issue.

Best regards

Sebastian

-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] Cpack with Bundleutilities on Windows

[baschdel_98]

Hello everyone,

 

I'm new to cmake so this will be a, more or less, stupid question.

I'm creating an multiplatform application that is dependent on curl, Qt, and ffmpeg.
I'd like to link them statically.

 

On Windows is the need to include the *.dll files. I tried to use fixup_bundle() for this purpose at install time.
This works like a charm. So no problem theire.

 

The problem starts when I'd like to pack the application. For this I'm using WIX and 7ZIP.

In neither of the created installer are the *.dll included.

 

I'm not sure where the problem is.

This is my code:

 

set(RELATIV_INSTALL_DIRECTORY "bin")
install(TARGETS ${CMAKE_PROJECT_NAME} 
    DESTINATION ${RELATIV_INSTALL_DIRECTORY}
    COMPONENT app)

 

# DIRS contains all directories the *dll files are located
set(executable_path "\${CMAKE_INSTALL_PREFIX}/${RELATIV_INSTALL_DIRECTORY}/${CMAKE_PROJECT_NAME}.exe")

 

install(CODE "
    include (BundleUtilities)
    fixup_bundle(\"${executable_path}\" \"\" \"${DIRS}\")
    "
    COMPONENT app)

 


set(CPACK_OUTPUT_FILE_PREFIX "${CMAKE_BINARY_DIR}/package")

set(CPACK_PACKAGE_NAME "${CMAKE_PROJECT_NAME}")
set(CPACK_PACKAGE_VENDOR "${COMPANY_NAME}")
set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "Installer for ${CMAKE_PROJECT_NAME}.")
set(CPACK_PACKAGE_VERSION_MAJOR "${PROJECT_VERSION_MAJOR}")
set(CPACK_PACKAGE_VERSION_MINOR "${PROJECT_VERSION_MINOR}")
set(CPACK_PACKAGE_VERSION_PATCH "${PROJECT_VERSION_PATCH}")
set(CPACK_PACKAGE_VERSION "${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}")
set(CPACK_PACKAGE_INSTALL_DIRECTORY "company/${CMAKE_PROJECT_NAME}")

set(CPACK_COMPONENTS_ALL app)

set(CPACK_RESOURCE_FILE_LICENSE "${CMAKE_SOURCE_DIR}/license.txt")


if(WIN32)
    set(CPACK_WIX_UI_DIALOG "${CMAKE_CURRENT_SOURCE_DIR}/res/windows/welcome.bmp")
    # set(CPACK_WIX_PRODUCT_ICON "${CMAKE_CURRENT_SOURCE_DIR}/res/windows/Logo.ico")
    set(CPACK_WIX_UI_BANNER "${CMAKE_CURRENT_SOURCE_DIR}/res/windows/header.bmp")
    set(CPACK_GENERATOR WIX;7Z)
endif()

include(CPack)

I'm not sure why it won't show in the geerated installers.

 

Best regards,
Seabstian

-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] building cmake without the bootstrap step

[René J . V . Bertin]

Never mind, this tweak to the bootstrap script should take care of anything not 
directly obvious. Could do with an automated test of the installed version but 
the accepted version range is so large that doesn't seem to be the trouble.

```
if [ -x ${cmake_prefix_dir}/bin/cmake ] ;then
  # use the existing cmake that we'll be replacing.
  ln -s ${cmake_prefix_dir}/bin/cmake ${cmake_bootstrap_dir}/cmake
else
  # Run make to build bootstrap cmake
  if [ "x${cmake_parallel_make}" != "x" ]; then
${cmake_make_processor} ${cmake_make_flags}
  else
${cmake_make_processor}
  fi
  RES=$?
  if [ "${RES}" -ne "0" ]; then
cmake_error 9 "Problem while running ${cmake_make_processor}"
  fi
fi
cd "${cmake_binary_dir}"
```

R
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] building cmake without the bootstrap step

[René J . V . Bertin]

On Thursday December 12 2019 09:36:03 Kyle Edwards wrote:

>If you want to skip bootstrapping, you can use a pre-existing CMake
>binary for your system to build the new CMake.
>
>This mailing list is deprecated. Please head over to Discourse for
>further discussion:

OK, thanks. To finish things up here, there is thus nothing in the arguments to 
the bootstrap script that is crucial and cannot be set via a preexisting cmake 
command?

R.
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

Re: [CMake] building cmake without the bootstrap step

[Kyle Edwards via CMake]

On Thu, 2019-12-12 at 15:15 +0100, René J.V. Bertin wrote:
> Hi,
> 
> If I understand correctly, configuring CMake for building means
> bootstrapping a basic version of itself which is then run on the
> included CMakeLists.txt file. That takes a lot of time
> (comparatively) which begs the question if there's a more-of-less
> official way to skip the bootstrap and just use the installed cmake
> binary?

The bootstrap CMake does not have all of the capabilities of the real
CMake - just enough to build CMake itself. It is intended to be used
once to build the real CMake and then immediately discarded.

If you want to skip bootstrapping, you can use a pre-existing CMake
binary for your system to build the new CMake.

This mailing list is deprecated. Please head over to Discourse for
further discussion:

https://discourse.cmake.org/c/usage

Kyle
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] building cmake without the bootstrap step

[René J . V . Bertin]

Hi,

If I understand correctly, configuring CMake for building means bootstrapping a 
basic version of itself which is then run on the included CMakeLists.txt file. 
That takes a lot of time (comparatively) which begs the question if there's a 
more-of-less official way to skip the bootstrap and just use the installed 
cmake binary?

Thanks,
René
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] CMake on host executing compiler inside docker

[Federico Kircheis]

Hello,

I'm trying to solve following problem.

test as many different compilers as possible with no (or minimal) 
maintenance burden.


As docker is the newest trend, I decided to give it a try (nearly using 
it for the first time).
Also the GCC team has official docker images 
(https://hub.docker.com/_/gcc/), so I decided to give it a try.


The main advantage is that I do not need to manage, compile and package 
myself all different compiler versions for my operating system.



The issue is that the integration between tools inside docker images and 
tools outside docker images is very bad.



I do not want to install CMake (and other tools) on those images as I 
could see on many projects because


  * it does not scale at all if I want to also test different version 
of CMake, make, ninja, clang, ...
  * It's a maintenance burden, as every time the base image gets 
updated, I need to update my modified images too
  * If I modify the official image, I need to know internal details 
that are not really relevant for testing the compiler (what OS, package 
manager, directory structure, ...)
  * It does not solve the integration issue, I do not think that 
installing the whole IDE would be a good idea.



At that point, compiling and packaging for the host platform is probably 
easier.



So what I tried was to take the docker images, and let my local CMake 
(CMake on the host, not in docker), use the compiler in the docker image.


This would have following advantages

  * compiler and build system are decoupled, I can easily test many 
version combinations of the two
  * No need to know how the image is build, I'm using it as a black 
box, as originally intended.
  * As most IDE understand make or CMake, I have the integration with 
the dockerized compiler for free (probably for other tools too)


I've created following toolchain file


set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_CROSSCOMPILING TRUE)

# FIXME: instead of hard coding 1000, map for real user id...
# Good enough for now as generated files are not owned by root
set(command 
"docker;run;--env;VERBOSE=1;-v;${CMAKE_SOURCE_DIR}:${CMAKE_SOURCE_DIR};-w;${CMAKE_SOURCE_DIR};--user;1000;gcc:5")


foreach(LANG C CXX ASM)
set(CMAKE_${LANG}_COMPILER_LAUNCHER ${command} CACHE STRING "")
endforeach()
#set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE "docker run --env 
VERBOSE=1 -v ${CMAKE_SOURCE_DIR}:${CMAKE_SOURCE_DIR} -w 
${CMAKE_SOURCE_DIR} --user 1000 gcc:5")



set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)


(the second attempt was setting `set_property(GLOBAL PROPERTY 
RULE_LAUNCH_COMPILE "docker run --env VERBOSE=1 -v 
${CMAKE_SOURCE_DIR}:${CMAKE_SOURCE_DIR} -w ${CMAKE_SOURCE_DIR} --user 
1000 gcc:5")`, but it did not make any difference)


and used it like



m -rf build;cmake -S . -B build 
-DCMAKE_TOOLCHAIN_FILE=toolchain-docker.cmake --debug-trycompile && 
cmake --build build



I can see that the makefiles all have "docker run " commands, which 
looks great, but CMake, in it's internal logic, does not seem to always 
apply the `RULE_LAUNCH_COMPILE` and `CMAKE_${LANG}_COMPILER_LAUNCHER`, 
as the output looks like:



-- The C compiler identification is GNU 9.2.1 



-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works


GCC 9.2.1 is the compiler on my local host, the output should have been 
version 5.


I've also noticed that internal tests, like 
/usr/share/cmake-3.13/Modules/CMakeTestCCompiler.cmake:52, gets executed 
with the "docker run" prefix, and they do not fail.



Is there some parameter that I'm missing, or is there a better way to 
achieve what I'm trying to do?


I can also verify that CMake does not always apply "RULE_LAUNCH_COMPILE" 
and "CMAKE_${LANG}_COMPILER_LAUNCHER", because if I add 
"set(CMAKE_C_COMPILER /usr/local/bin/gcc)" (which is the internal path 
in docker), then CMake prints



-- The C compiler identification is unknown
-- The ASM compiler identification is unknown
-- Didn't find assembler
CMake Error at CMakeLists.txt:12 (project):
  The CMAKE_C_COMPILER:

/usr/local/bin/gcc

  is not a full path to an existing compiler tool.

  Tell CMake where to find the compiler by setting either the environment
  variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full 
path to

  the compiler, or to the compiler name if it is in the PATH.


as GCC on my host is "/usr/bin/gcc".
--

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This 

[CMake] ANNOUNCE] CMake 3.16.1 available for download

[Robert Maynard via CMake]

We are pleased to announce that CMake 3.16.1 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-
Changes in 3.16.1 since 3.16.0:

Alexander Grund (2):
  bootstrap: Add target_link_options command
  Check for support before adding bigtoc linker flag

Ben Boeckel (1):
  TestDriver: ignore strcpy call

Brad King (2):
  FindThreads: Restore hard-coded '-l' flag on library name
  CMake 3.16.1

Cristian Adam (5):
  PCH: Do not add #pragma system_header for Xcode generator
  Unity/PCH: Skip more target types when adding automatic sources
  Unity: Generic source file handling for all generators
  Unity: Proper handling of object libraries
  PCH: Use the target's PREFIX for building the pdb file name

Kyle Edwards (1):
  CTest Resource Allocation: Add test for spec file with no version

Tobias Taschner (1):
  FindwxWidgets: Add support for 3.1.3 on macOS
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] CMakeLists.txt : Link options not working properly

[samyuktar]

Hello,

I am using the TI-CGT compiler and have been successful in getting all my
source files to compile. However, I am unable to get the link command to
successfully link, and I have crafted a manual link command which I have to
then manually enter into the terminal once the build compiles all the files
and fails at the link stage. 
I derived the link command from Code Composer Studio and took guidance for
what libraries are missing. However when I tried to add this to the
target_link_libraries in CMake, that didn't work.

Here is my manual link command:

"/Applications/ti_ccs9/ccs9/ccs/tools/compiler/ti-cgt-arm_18.12.2.LTS/bin/armcl"
-mv7M4 --code_state=16 --float_support=FPv4SPD16 -me
--define=DeviceFamily_CC13X2 -g --diag_warning=225 --diag_warning=255
--diag_wrap=off --display_error_number --gen_func_subsections=on -z
-m"lwipthreads_CC1352P1_LAUNCHXL_tirtos_ccs.map"
-i"/Applications/ti_ccs9/simplelink_cc13x2_26x2_sdk_3_20_00_68/source"
-i"/Applications/ti_ccs9/simplelink_cc13x2_26x2_sdk_3_20_00_68/kernel/tirtos/packages"
-i"/Applications/ti_ccs9/ccs9/ccs/tools/compiler/ti-cgt-arm_18.12.2.LTS/lib"
--diag_wrap=off --display_error_number --warn_sections
--xml_link_info="lwipthreads_CC1352P1_LAUNCHXL_tirtos_ccs_linkInfo.xml"
--rom_model --output_file="lwipthreads_CC1352P1_LAUNCHXL_tirtos_ccs.out" 
"CMakeFiles/test.out.dir/main_tirtos.c.obj"
"../CC1352P1_LAUNCHXL_TIRTOS.cmd"
-l"/Applications/ti_ccs9/simplelink_cc13x2_26x2_sdk_3_20_00_68/source/ti/grlib/lib/ccs/m4f/grlib.a"
-lliblwipcontribapps.a  -lliblwipboard.a -lliblwipcore.a
-lliblwipcontribporttirtos.a -l"ti/display/lib/display.aem4f"
-l"/Applications/ti_ccs9/simplelink_cc13x2_26x2_sdk_3_20_00_68/source/third_party/spiffs/lib/ccs/m4f/spiffs_cc26xx.a"
-l"/Applications/ti_ccs9/simplelink_cc13x2_26x2_sdk_3_20_00_68/source/ti/drivers/rf/lib/rf_multiMode_cc13x2.aem4f"
-l"/Applications/ti_ccs9/simplelink_cc13x2_26x2_sdk_3_20_00_68/source/ti/drivers/lib/drivers_cc13x2.aem4f"
-l"/Applications/ti_ccs9/simplelink_cc13x2_26x2_sdk_3_20_00_68/kernel/tirtos/packages/ti/dpl/lib/dpl_cc13x2.aem4f"
-l"../linker.cmd"
-l"/Applications/ti_ccs9/simplelink_cc13x2_26x2_sdk_3_20_00_68/source/ti/devices/cc13x2_cc26x2/driverlib/bin/ccs/driverlib.lib"
-llibc.a


Here, liblwipcore.a, liblwipcontribporttirtos.a, liblwipboard.a,
liblwipcontribapps.a, are libraries that I have made using my
CMakeLists.txt. The rest are standard libraries coming from TI's SDK.

The other thing is that I am unable to add the
../CC1352P1_LAUNCHXL_TIRTOS.cmd in the CMakeLists.txt the way that I need it
in the linker command that I added above. This file has some information
about sections for .data, .code, .bss, flash memory partitions and the
system memory map etc. so it is definitely required by the CC1352P1 board to
be able to run this on the board. 

Here is what I have in CMakeLists.txt for the link step :

set( cc1352p1_libs
${TIRTOS_SDK}/source/ti/display/lib/display.aem4f
${TIRTOS_SDK}/source/ti/grlib/lib/ccs/m4f/grlib.a
${TIRTOS_SDK}/source/third_party/spiffs/lib/ccs/m4f/spiffs_cc26xx.a
${TIRTOS_SDK}/source/ti/drivers/rf/lib/rf_multiMode_cc13x2.aem4f
${TIRTOS_SDK}/source/ti/drivers/lib/drivers_cc13x2.aem4f
${TIRTOS_SDK}/kernel/tirtos/packages/ti/dpl/lib/dpl_cc13x2.aem4f
   
${TIRTOS_SDK}/source/ti/devices/cc13x2_cc26x2/driverlib/bin/ccs/driverlib.lib
#   ${TIRTOS_SDK}/source/third_party/fatfs/lib/ccs/m4/fatfs.a
   
/Applications/ti_ccs9/ccs9/ccs/tools/compiler/ti-cgt-arm_18.12.2.LTS/lib/rtsv7M4_T_le_v4SPD16_eabi.lib
${LWIP_DIR}/linker.cmd
)

set( cc1352p1_lib_dirs
${TIRTOS_SDK}/source/ti/display/lib
${TIRTOS_SDK}/source/ti/grlib/lib/ccs/m4f
${TIRTOS_SDK}/source/third_party/spiffs/lib/ccs/m4f
${TIRTOS_SDK}/source/ti/drivers/rf/lib
${TIRTOS_SDK}/source/ti/drivers/lib
${TIRTOS_SDK}/kernel/tirtos/packages/ti/dpl/lib
${TIRTOS_SDK}/source/ti/devices/cc13x2_cc26x2/driverlib/bin/ccs
${TIRTOS_SDK}/source/third_party/fatfs/lib/ccs/m4
   
/Applications/ti_ccs9/ccs9/ccs/tools/compiler/ti-cgt-arm_18.12.2.LTS/lib
)

add_link_options(test.out ../CC1352P1_LAUNCHXL_TIRTOS.cmd)
target_link_libraries(test.out  lwipcontribapps lwipboard
lwipcontribporttirtos  lwipcontribexamples lwipcore
${CMAKE_COMPILER_PATH}/lib/libc.a ${cc1352p1_libs})
add_definitions( ${LWIP_COMPILE_OPTIONS}) #   ${LWIP_BIOS_OPTS} )

Here's the error that I get when I say make:

>> WARNING: invalid linker option
>> --warn_sections--xml_link_info=gpiointerrupt_CC1352P1_LAUNCHXL_tirtos_ccs_linkInfo.xml
>> (ignored)

error #10056: symbol "free" redefined: first defined in
  
"/Users/sramnath/ccs_workspaces/sdk_3_2/spiEthernet/tirtos_builds_CC1352P1_L
   AUNCHXL_release_ccs/Debug/configPkg/package/cfg/release_pem4f.oem4f";
   redefined in
  
"/Applications/ti_ccs9/ccs9/ccs/tools/compiler/ti-cgt-arm_18.12.2.LTS/lib/rt
   sv7M4_T_le_v4SPD16_eabi.lib"
error #10056: symbol "realloc" redefined: first defined in
  

[Cmake-commits] CMake branch, master, updated. v3.16.0-428-gf7ca8fc24c

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  f7ca8fc24ccb4e7724d2228d9997b2df99e71133 (commit)
  from  c57bcf3b3025875dfbfd1d1f6eca1291abf4d2f7 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f7ca8fc24ccb4e7724d2228d9997b2df99e71133
commit f7ca8fc24ccb4e7724d2228d9997b2df99e71133
Author: Kitware Robot 
AuthorDate: Wed Dec 4 00:01:08 2019 -0500
Commit: Kitware Robot 
CommitDate: Wed Dec 4 00:01:08 2019 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index f337884b4c..828c9652af 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191203)
+set(CMake_VERSION_PATCH 20191204)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

Summary of changes:
 Source/CMakeVersion.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.16.0-427-gc57bcf3b30

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  c57bcf3b3025875dfbfd1d1f6eca1291abf4d2f7 (commit)
  from  735d731119e731c8a321f85824ee685005b38731 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c57bcf3b3025875dfbfd1d1f6eca1291abf4d2f7
commit c57bcf3b3025875dfbfd1d1f6eca1291abf4d2f7
Author: Kitware Robot 
AuthorDate: Tue Dec 3 00:01:07 2019 -0500
Commit: Kitware Robot 
CommitDate: Tue Dec 3 00:01:07 2019 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 97a182fdac..f337884b4c 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191202)
+set(CMake_VERSION_PATCH 20191203)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

Summary of changes:
 Source/CMakeVersion.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.16.0-426-g735d731119

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  735d731119e731c8a321f85824ee685005b38731 (commit)
  from  ff270b8d337bd3fe7b95587c87e261b7f5893ea4 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=735d731119e731c8a321f85824ee685005b38731
commit 735d731119e731c8a321f85824ee685005b38731
Author: Kitware Robot 
AuthorDate: Mon Dec 2 00:01:08 2019 -0500
Commit: Kitware Robot 
CommitDate: Mon Dec 2 00:01:08 2019 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 589666e610..97a182fdac 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191201)
+set(CMake_VERSION_PATCH 20191202)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

Summary of changes:
 Source/CMakeVersion.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.16.0-425-gff270b8d33

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  ff270b8d337bd3fe7b95587c87e261b7f5893ea4 (commit)
  from  7cd0c2be0154436ec459829dcc1eee192586e486 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ff270b8d337bd3fe7b95587c87e261b7f5893ea4
commit ff270b8d337bd3fe7b95587c87e261b7f5893ea4
Author: Kitware Robot 
AuthorDate: Sun Dec 1 00:01:06 2019 -0500
Commit: Kitware Robot 
CommitDate: Sun Dec 1 00:01:06 2019 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 1b333c9566..589666e610 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191130)
+set(CMake_VERSION_PATCH 20191201)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

Summary of changes:
 Source/CMakeVersion.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.16.0-424-g7cd0c2be01

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  7cd0c2be0154436ec459829dcc1eee192586e486 (commit)
  from  ca2a3929c2c7d479b12bab96d1910eff87380861 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7cd0c2be0154436ec459829dcc1eee192586e486
commit 7cd0c2be0154436ec459829dcc1eee192586e486
Author: Kitware Robot 
AuthorDate: Sat Nov 30 00:01:09 2019 -0500
Commit: Kitware Robot 
CommitDate: Sat Nov 30 00:01:09 2019 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 4d44e09aed..1b333c9566 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191129)
+set(CMake_VERSION_PATCH 20191130)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

Summary of changes:
 Source/CMakeVersion.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.16.0-423-gca2a3929c2

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  ca2a3929c2c7d479b12bab96d1910eff87380861 (commit)
  from  7fe99b813c6772f056fddc2c6ea7f73ccb3d3e1c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ca2a3929c2c7d479b12bab96d1910eff87380861
commit ca2a3929c2c7d479b12bab96d1910eff87380861
Author: Kitware Robot 
AuthorDate: Fri Nov 29 00:01:07 2019 -0500
Commit: Kitware Robot 
CommitDate: Fri Nov 29 00:01:07 2019 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 1e2e078ac0..4d44e09aed 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191128)
+set(CMake_VERSION_PATCH 20191129)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

Summary of changes:
 Source/CMakeVersion.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.16.0-422-g7fe99b813c

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  7fe99b813c6772f056fddc2c6ea7f73ccb3d3e1c (commit)
  from  53bc2000a4dc5296338f5997497c8f1d435fc259 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7fe99b813c6772f056fddc2c6ea7f73ccb3d3e1c
commit 7fe99b813c6772f056fddc2c6ea7f73ccb3d3e1c
Author: Kitware Robot 
AuthorDate: Thu Nov 28 00:01:11 2019 -0500
Commit: Kitware Robot 
CommitDate: Thu Nov 28 00:01:11 2019 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 4bf7bcf825..1e2e078ac0 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191127)
+set(CMake_VERSION_PATCH 20191128)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

Summary of changes:
 Source/CMakeVersion.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, release, updated. v3.16.0-2-g85fb95562b

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, release has been updated
   via  85fb95562bb7f04664f0b47d20f248c9779ff61f (commit)
   via  59df85194e47ea330478410092ddb9c6fcb17163 (commit)
  from  1b4482f65dd41f21ec8abc0777b8dc1f0381bbd6 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
---

Summary of changes:
 Tests/CMakeLib/testCTestResourceSpec.cxx   | 1 +
 Tests/CMakeLib/testCTestResourceSpec_data/{spec19.json => spec36.json} | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)
 copy Tests/CMakeLib/testCTestResourceSpec_data/{spec19.json => spec36.json} 
(56%)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.16.0-421-g53bc2000a4

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  53bc2000a4dc5296338f5997497c8f1d435fc259 (commit)
   via  398dfc1338eb2ccd98ae5513fe6ebeb019cf7bcd (commit)
   via  85fb95562bb7f04664f0b47d20f248c9779ff61f (commit)
   via  59df85194e47ea330478410092ddb9c6fcb17163 (commit)
  from  7046a5219893436cbe19b6973ac13fb489199601 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=53bc2000a4dc5296338f5997497c8f1d435fc259
commit 53bc2000a4dc5296338f5997497c8f1d435fc259
Merge: 398dfc1338 85fb95562b
Author: Kyle Edwards 
AuthorDate: Thu Nov 28 03:48:08 2019 +
Commit: Kitware Robot 
CommitDate: Wed Nov 27 22:48:20 2019 -0500

Merge branch 'release-3.16'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=398dfc1338eb2ccd98ae5513fe6ebeb019cf7bcd
commit 398dfc1338eb2ccd98ae5513fe6ebeb019cf7bcd
Merge: 7046a52198 59df85194e
Author: Kyle Edwards 
AuthorDate: Thu Nov 28 03:48:08 2019 +
Commit: Kitware Robot 
CommitDate: Wed Nov 27 22:48:20 2019 -0500

Merge topic 'ctest-spec-file-version-test'

59df85194e CTest Resource Allocation: Add test for spec file with no version

Acked-by: Kitware Robot 
Merge-request: !4092


---

Summary of changes:
 Tests/CMakeLib/testCTestResourceSpec.cxx   | 1 +
 Tests/CMakeLib/testCTestResourceSpec_data/{spec19.json => spec36.json} | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)
 copy Tests/CMakeLib/testCTestResourceSpec_data/{spec19.json => spec36.json} 
(56%)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.16.0-417-g7046a52198

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  7046a5219893436cbe19b6973ac13fb489199601 (commit)
  from  ffe801062a63387b2c109eda034d74830d72a4ce (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7046a5219893436cbe19b6973ac13fb489199601
commit 7046a5219893436cbe19b6973ac13fb489199601
Author: Kitware Robot 
AuthorDate: Wed Nov 27 00:01:12 2019 -0500
Commit: Kitware Robot 
CommitDate: Wed Nov 27 00:01:12 2019 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 249727851b..4bf7bcf825 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191126)
+set(CMake_VERSION_PATCH 20191127)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

Summary of changes:
 Source/CMakeVersion.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[CMake] [ANNOUNCE] CMake 3.16.0 available for download

[Robert Maynard via CMake]

I am happy to announce that CMake 3.16.0 is now available for download at:
  https://cmake.org/download/

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

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

Some of the more significant changes in CMake 3.16 are:

* CMake learned to support the Objective C ("OBJC") and Objective
  C++ ("OBJCXX") languages.  They may be enabled via the "project()"
  and "enable_language()" commands.  When "OBJC" or "OBJCXX" is
  enabled, source files with the ".m" or ".mm", respectively, will be
  compiled as Objective C or C++.  Otherwise they will be treated as
  plain C++ sources as they were before.

* The "target_precompile_headers()" command was added to specify a
  list of headers to precompile for faster compilation times.

* The "UNITY_BUILD" target property was added to tell generators to
  batch include source files for faster compilation times.

* The "find_file()", "find_library()", "find_path()",
  "find_package()", and "find_program()" commands have learned to
  check the following variables to control searching

  * "CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH" - Controls the searching
the cmake-specific environment variables.

  * "CMAKE_FIND_USE_CMAKE_PATH" - Controls the searching the cmake-
specific cache variables.

  * "CMAKE_FIND_USE_CMAKE_SYSTEM_PATH" - Controls the searching
cmake platform specific variables.

  * "CMAKE_FIND_USE_PACKAGE_ROOT_PATH" - Controls the searching of
"_ROOT" variables.

  * "CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH" - Controls the
searching the standard system environment variables.

* The "file()" command learned a new sub-command,
  "GET_RUNTIME_DEPENDENCIES", which allows you to recursively get the
  list of libraries linked by an executable or library. This sub-
  command is intended as a replacement for "GetPrerequisites".

* "ctest(1)" now has the ability to serialize tests based on
  resource requirements for each test. See Resource Allocation for
  details.

* On AIX, executables using the "ENABLE_EXPORTS" target property now
  produce a linker import file with a ".imp" extension in addition to
  the executable file.  Plugins (created via "add_library()" with the
  "MODULE" option) that use "target_link_libraries()" to link to the
  executable for its symbols are now linked using the import file. The
  "install(TARGETS)" command now installs the import file as an
  "ARCHIVE" artifact.

* On AIX, runtime linking is no longer enabled by default.  CMake
  provides the linker enough information to resolve all symbols up
  front. One may manually enable runtime linking for shared libraries
  and/or loadable modules by adding "-Wl,-G" to their link flags (e.g.
  in the "CMAKE_SHARED_LINKER_FLAGS" or "CMAKE_MODULE_LINKER_FLAGS"
  variable). One may manually enable runtime linking for executables
  by adding "-Wl,-brtl" to their link flags (e.g. in the
  "CMAKE_EXE_LINKER_FLAGS" variable).

* "cmake(1)" "-E" now supports "true" and "false" commands, which do
  nothing while returning exit codes of 0 and 1, respectively.

* "cmake(1)" gained a "--trace-redirect=" command line option
  that can be used to redirect "--trace" output to a file instead of
  "stderr".

* The "cmake(1)" "--loglevel" command line option has been renamed
  to "--log-level" to make it consistent with the naming of other
  command line options.  The "--loglevel" option is still supported to
  preserve backward compatibility.

* The "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" variable has been
  deprecated.  Use the "CMAKE_FIND_USE_PACKAGE_REGISTRY" variable
  instead.

* The "GetPrerequisites" module has been deprecated, as it has been
  superceded by "file(GET_RUNTIME_DEPENDENCIES)".


CMake 3.16 Release Notes


Changes made since CMake 3.15 include the following.


New Features



Languages
-

* CMake learned to support the Objective C ("OBJC") and Objective
  C++ ("OBJCXX") languages.  They may be enabled via the "project()"
  and "enable_language()" commands.  When "OBJC" or "OBJCXX" is
  enabled, source files with the ".m" or ".mm", respectively, will be
  compiled as Objective C or C++.  Otherwise they will be treated as
  plain C++ sources as they were before.


Compilers
-

* The "Clang" compiler is now supported on "Solaris".


Platforms
-

* On AIX, executables using the "ENABLE_EXPORTS" target property now
  produce a linker import file with a ".imp" extension in addition to
  the executable file.  Plugins (created via "add_library()" with the
  "MODULE" option) that use "target_link_libraries()" to link to the
  executable for its symbols are now linked using the import file. The
  "install(TARGETS)" command now installs the import file as an
  "ARCHIVE" artifact.

* On AIX, runtime linking is no longer enabled by default.  CMake
  provides the linker enough information to resolve all symbols up
  

[Cmake-commits] CMake annotated tag, v3.16.0, created. v3.16.0

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The annotated tag, v3.16.0 has been created
at  24176cbf3f521c8e6704e9d9746ed42537527ade (tag)
   tagging  1b4482f65dd41f21ec8abc0777b8dc1f0381bbd6 (commit)
  replaces  v3.16.0-rc4
 tagged by  Brad King
on  Tue Nov 26 10:21:49 2019 -0500

- Log -
CMake 3.16.0
-BEGIN PGP SIGNATURE-

iQJKBAABCgA0FiEExsJlMku+vcNQtRPQLSzvEDSSFoQFAl3dQw0WHGJyYWQua2lu
Z0BraXR3YXJlLmNvbQAKCRAtLO8QNJIWhCA8EACnOAQ20KwRFXEyFmVoU0B+fsxe
ViBjXjk2HTMR3obbB95vu4GZ/+0qAkqIN+rpvW//OZhpAgPYwQzwPPSVyjhAoTP8
YcEoyqs8LzMpytaE1gZPx17PCsATWni3ggYncgZwGF1UUaz5x4jYU4Of6gjWnWxQ
Codq4iABZE8oZI04vOAbF2OgtSA8kPvDE0I3f1feX4HVzvJSVlhPvPlSadmqY11x
hHgnVAhCDEHehdwcCIjKwtRWDoBjV7muk+Pk1AJvEQfzvhnY2TWYb6Ik0/JHaaAs
eSHxMa6VIswnvn2VK5dR/Uc2Fu9eBvSQ8AbrgUPHpY95/47PmHyNAZWlJxEEWzgT
Ak9Vgds1yPRg7NAnkItprV/Jsc+aDL/BxcoyuHBadcvlL75OgVV1MZQ/bOIEbZHo
BwK+TnRq8D82xVP+1pnKTSYrZqV+22Lfl9VosvTnqSYxj17DHeFiuNkrCkSUOH6d
wLtq2TfVtu0TpRow0ABcMhr8VGnMfYCdGYdf4UF3n1hSI96DExS4NbzQUBzd4KVj
fGJehAE8+rUOgsgrjNSyfylxvnUT5jn2fQpyTywmifEYL17+nyaJY9b7hF7yKX89
O5QuvJxZI452BBl9SbM7bv9CYgp6VsIRk22epqDOpLzLB6elv7C3Vei0ZCieLYWo
jT6oNjaqQJ7g/P9Ddg==
=U1/L
-END PGP SIGNATURE-

Brad King (18):
  VS: Tell VS 16.4 not to verify CMake-provided custom command outputs
  Merge branch 'backport-vs-16.4-global-targets' into release-3.15
  Merge branch 'vs-v142-csharp-flags' into release-3.15
  Merge branch 'InstallRequiredSystemLibraries-redist' into release-3.15
  Merge branch 'doc-genex-tweak' into release-3.15
  CMake 3.15.5
  Xcode: Set source file type for Objective C/C++
  Merge topic 'FindwxWidgets-qt-debug' into release-3.16
  Merge topic 'xcode-objc' into release-3.16
  FindwxWidgets: Fix finding both release and debug libs
  Merge topic 'FindwxWidgets-rel-and-dbg' into release-3.16
  CMakeParseImplicitIncludeInfo: Remove all CR chars from compiler output
  Merge topic 'unity-no-duplicate-path' into release-3.16
  Merge topic 'FindODBC-mingw' into release-3.16
  Merge branch 'backport-implicit-includes-extra-CR' into 
implicit-includes-extra-CR
  Merge topic 'implicit-includes-extra-CR' into release-3.16
  Merge topic 'ctest-resource-fixes' into release-3.16
  CMake 3.16.0

Craig Sturdy (1):
  FindwxWidgets: Find wxQt debug libraries

Cristian Adam (2):
  Unity: No repeated path for internal generated unity files
  FindODBC: Add library name for MinGW toolchains

Kyle Edwards (3):
  CTest: Add version field to resource spec file
  CTest: Clarify that resource requirements can be split
  Help: Clarify how tests are run if no resource spec file is specified

---


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, release, updated. v3.16.0-rc4-24-g1b4482f65d

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, release has been updated
   via  1b4482f65dd41f21ec8abc0777b8dc1f0381bbd6 (commit)
  from  b1175431c385cb052769d4575576ebb19b6e594b (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
---

Summary of changes:
 Source/CMakeVersion.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc4-440-gffe801062a

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  ffe801062a63387b2c109eda034d74830d72a4ce (commit)
   via  1b4482f65dd41f21ec8abc0777b8dc1f0381bbd6 (commit)
  from  797e55a5ef718f8762b393358c3f221c314f21d1 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ffe801062a63387b2c109eda034d74830d72a4ce
commit ffe801062a63387b2c109eda034d74830d72a4ce
Merge: 797e55a5ef 1b4482f65d
Author: Brad King 
AuthorDate: Tue Nov 26 10:18:59 2019 -0500
Commit: Brad King 
CommitDate: Tue Nov 26 10:18:59 2019 -0500

Merge branch 'release-3.16'


---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

Re: [cmake-developers] [ANNOUNCE] CMake Discourse forum now available

[Robert Maynard via cmake-developers]

> To facilitate a transition period, the current mailman-based mailing lists
> will remain active until at least the end of March 2020, and their archives
> will remain available after that.

This transition period was announced both on the users list and here
on the developers list.
Since the developers list is fairly low traffic and there are not
currently any active threads, we've decided to close this list now.
Please post to the CMake Discourse "Development" category instead:

  https://discourse.cmake.org/c/development

See you on discourse.cmake.org!
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

This mailing list is deprecated in favor of https://discourse.cmake.org

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc4-438-g797e55a5ef

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  797e55a5ef718f8762b393358c3f221c314f21d1 (commit)
   via  19f267c75e84b72c4de42570be0c4222bb93aaff (commit)
  from  ff198efc77e7b2401aa5cc4d7b6b7c91838dde7b (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=797e55a5ef718f8762b393358c3f221c314f21d1
commit 797e55a5ef718f8762b393358c3f221c314f21d1
Merge: ff198efc77 19f267c75e
Author: Brad King 
AuthorDate: Tue Nov 26 14:14:26 2019 +
Commit: Kitware Robot 
CommitDate: Tue Nov 26 09:14:33 2019 -0500

Merge topic 'xlf-ninja'

19f267c75e XL: Add support for Ninja and XL Fortran

Acked-by: Kitware Robot 
Merge-request: !4075


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=19f267c75e84b72c4de42570be0c4222bb93aaff
commit 19f267c75e84b72c4de42570be0c4222bb93aaff
Author: Brad King 
AuthorDate: Thu Nov 21 14:38:35 2019 -0500
Commit: Brad King 
CommitDate: Thu Nov 21 15:59:12 2019 -0500

XL: Add support for Ninja and XL Fortran

The Ninja generator's support for Fortran requires that source files
be preprocessed explicitly first.  However, the `xlf` compiler does
not have a simple `-E` option or equivalent to do preprocessing.
The only documented way to get preprocessed output is to use `-d`
to leave it behind, but only at an inflexible location.

Instead, create our own `cpp` wrapper script and substitute it for the
real preprocessor using `-tF -B ...`.  Teach the wrapper to map the
`cpp` output to the location we need and then invoke the real `cpp`
underneath.

Fixes: #19450

diff --git a/Help/release/dev/xlf-ninja.rst b/Help/release/dev/xlf-ninja.rst
new file mode 100644
index 00..916e713008
--- /dev/null
+++ b/Help/release/dev/xlf-ninja.rst
@@ -0,0 +1,5 @@
+xlf-ninja
+-
+
+* The IBM XL Fortran compiler is now supported by the :generator:`Ninja`
+  generator.
diff --git a/Modules/CMakeDetermineCompilerId.cmake 
b/Modules/CMakeDetermineCompilerId.cmake
index f7ef755aeb..0b3664c5de 100644
--- a/Modules/CMakeDetermineCompilerId.cmake
+++ b/Modules/CMakeDetermineCompilerId.cmake
@@ -182,6 +182,10 @@ function(CMAKE_DETERMINE_COMPILER_ID lang flagvar src)
 message(STATUS "The ${lang} compiler identification is unknown")
   endif()
 
+  if(lang STREQUAL "Fortran" AND CMAKE_${lang}_COMPILER_ID STREQUAL "XL")
+set(CMAKE_${lang}_XL_CPP "${CMAKE_${lang}_COMPILER_ID_CPP}" PARENT_SCOPE)
+  endif()
+
   set(CMAKE_${lang}_COMPILER_ID "${CMAKE_${lang}_COMPILER_ID}" PARENT_SCOPE)
   set(CMAKE_${lang}_PLATFORM_ID "${CMAKE_${lang}_PLATFORM_ID}" PARENT_SCOPE)
   set(CMAKE_${lang}_COMPILER_ARCHITECTURE_ID 
"${CMAKE_${lang}_COMPILER_ARCHITECTURE_ID}" PARENT_SCOPE)
@@ -542,6 +546,12 @@ Id flags: ${testflags} 
${CMAKE_${lang}_COMPILER_ID_FLAGS_ALWAYS}
   ERROR_VARIABLE CMAKE_${lang}_COMPILER_ID_OUTPUT
   RESULT_VARIABLE CMAKE_${lang}_COMPILER_ID_RESULT
   )
+if("${CMAKE_${lang}_COMPILER_ID_OUTPUT}" MATCHES "exec: 
[^\n]*\\((/[^,\n]*/cpp),CMakeFortranCompilerId.F")
+  set(_cpp "${CMAKE_MATCH_1}")
+  if(EXISTS "${_cpp}")
+set(CMAKE_${lang}_COMPILER_ID_CPP "${_cpp}" PARENT_SCOPE)
+  endif()
+endif()
   endif()
 
   # Check the result of compilation.
diff --git a/Modules/CMakeDetermineFortranCompiler.cmake 
b/Modules/CMakeDetermineFortranCompiler.cmake
index 5ddd64fae8..e8505417d6 100644
--- a/Modules/CMakeDetermineFortranCompiler.cmake
+++ b/Modules/CMakeDetermineFortranCompiler.cmake
@@ -271,6 +271,11 @@ include(CMakeFindBinUtils)
 include(Compiler/${CMAKE_Fortran_COMPILER_ID}-FindBinUtils OPTIONAL)
 unset(_CMAKE_PROCESSING_LANGUAGE)
 
+if(CMAKE_Fortran_XL_CPP)
+  set(_SET_CMAKE_Fortran_XL_CPP
+"set(CMAKE_Fortran_XL_CPP \"${CMAKE_Fortran_XL_CPP}\")")
+endif()
+
 if(CMAKE_Fortran_COMPILER_ARCHITECTURE_ID)
   set(_SET_CMAKE_Fortran_COMPILER_ARCHITECTURE_ID
 "set(CMAKE_Fortran_COMPILER_ARCHITECTURE_ID 
${CMAKE_Fortran_COMPILER_ARCHITECTURE_ID})")
diff --git a/Modules/CMakeFortranCompiler.cmake.in 
b/Modules/CMakeFortranCompiler.cmake.in
index ae7b73ac4a..34f44aa542 100644
--- a/Modules/CMakeFortranCompiler.cmake.in
+++ b/Modules/CMakeFortranCompiler.cmake.in
@@ -6,6 +6,7 @@ set(CMAKE_Fortran_COMPILER_WRAPPER 
"@CMAKE_Fortran_COMPILER_WRAPPER@")
 set(CMAKE_Fortran_PLATFORM_ID "@CMAKE_Fortran_PLATFORM_ID@")
 set(CMAKE_Fortran_SIMULATE_ID "@CMAKE_Fortran_SIMULATE_ID@")
 set(CMAKE_Fortran_SIMULATE_VERSION "@CMAKE_Fortran_SIMULATE_VERSION@")
+@_SET_CMAKE_Fortran_XL_CPP@
 @_SET_CMAKE_Fortran_COMPILER_ARCHITECTURE_ID@
 @SET_MSVC_Fortran_ARCHITECTURE_ID@
 set(CMAKE_AR 

[Cmake-commits] CMake branch, release, updated. v3.16.0-rc4-23-gb1175431c3

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, release has been updated
   via  b1175431c385cb052769d4575576ebb19b6e594b (commit)
   via  a033bafbe01fcb4654f075955e0b3de7be81b0f7 (commit)
   via  a64ba0235fbacfe58751c222997bdd74cf973359 (commit)
   via  f9f294f5faf980aa39721e4deb465b2e9dbbbd9a (commit)
  from  8db38cfe3386c463ef40af8520a5df329f9fd596 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
---

Summary of changes:
 Help/manual/ctest.1.rst| 26 ++
 Help/prop_test/RESOURCE_GROUPS.rst | 16 +
 Source/CTest/cmCTestResourceSpec.cxx   | 26 ++
 Tests/CMakeLib/testCTestResourceGroups.cxx |  3 +++
 Tests/CMakeLib/testCTestResourceSpec.cxx   | 17 ++
 .../CMakeLib/testCTestResourceSpec_data/spec1.json |  4 
 .../testCTestResourceSpec_data/spec10.json |  4 
 .../testCTestResourceSpec_data/spec11.json |  4 
 .../testCTestResourceSpec_data/spec14.json |  4 
 .../testCTestResourceSpec_data/spec15.json |  4 
 .../testCTestResourceSpec_data/spec16.json |  4 
 .../testCTestResourceSpec_data/spec17.json |  4 
 .../testCTestResourceSpec_data/spec18.json |  4 
 .../{spec6.json => spec19.json}|  2 +-
 .../CMakeLib/testCTestResourceSpec_data/spec2.json |  4 
 .../testCTestResourceSpec_data/spec20.json |  8 +++
 .../{spec6.json => spec21.json}|  2 +-
 .../{spec6.json => spec22.json}|  2 +-
 .../testCTestResourceSpec_data/spec23.json |  7 ++
 .../testCTestResourceSpec_data/spec24.json |  7 ++
 .../testCTestResourceSpec_data/spec25.json |  8 +++
 .../testCTestResourceSpec_data/spec26.json |  8 +++
 .../testCTestResourceSpec_data/spec27.json |  8 +++
 .../testCTestResourceSpec_data/spec28.json |  8 +++
 .../testCTestResourceSpec_data/spec29.json |  5 +
 .../CMakeLib/testCTestResourceSpec_data/spec3.json |  4 
 .../{spec6.json => spec30.json}|  2 +-
 .../{spec6.json => spec31.json}|  2 +-
 .../{spec6.json => spec32.json}|  2 +-
 .../testCTestResourceSpec_data/spec33.json |  5 +
 .../testCTestResourceSpec_data/spec34.json |  5 +
 .../{spec6.json => spec35.json}|  2 +-
 .../CMakeLib/testCTestResourceSpec_data/spec4.json |  4 
 .../CMakeLib/testCTestResourceSpec_data/spec5.json |  4 
 .../CMakeLib/testCTestResourceSpec_data/spec6.json |  4 
 .../CMakeLib/testCTestResourceSpec_data/spec7.json |  4 
 .../CMakeLib/testCTestResourceSpec_data/spec8.json |  4 
 .../CMakeLib/testCTestResourceSpec_data/spec9.json |  4 
 .../CTestResourceAllocation/RunCMakeTest.cmake |  2 ++
 .../{notenough1.cmake => combine.cmake}|  2 +-
 .../CTestResourceAllocation/notenough1.cmake   |  2 +-
 .../CTestResourceAllocation/notenough2.cmake   |  2 +-
 ...ck.cmake => notenough3-ctest-s-res-check.cmake} |  0
 .../notenough3-ctest-s-res-result.txt} |  0
 .../notenough3-ctest-s-res-stderr.txt  |  4 
 .../{notenough2.cmake => notenough3.cmake} |  2 +-
 .../RunCMake/CTestResourceAllocation/resspec.json  |  4 
 47 files changed, 242 insertions(+), 11 deletions(-)
 copy Tests/CMakeLib/testCTestResourceSpec_data/{spec6.json => spec19.json} 
(56%)
 create mode 100644 Tests/CMakeLib/testCTestResourceSpec_data/spec20.json
 copy Tests/CMakeLib/testCTestResourceSpec_data/{spec6.json => spec21.json} 
(50%)
 copy Tests/CMakeLib/testCTestResourceSpec_data/{spec6.json => spec22.json} 
(56%)
 create mode 100644 Tests/CMakeLib/testCTestResourceSpec_data/spec23.json
 create mode 100644 Tests/CMakeLib/testCTestResourceSpec_data/spec24.json
 create mode 100644 Tests/CMakeLib/testCTestResourceSpec_data/spec25.json
 create mode 100644 Tests/CMakeLib/testCTestResourceSpec_data/spec26.json
 create mode 100644 Tests/CMakeLib/testCTestResourceSpec_data/spec27.json
 create mode 100644 Tests/CMakeLib/testCTestResourceSpec_data/spec28.json
 create mode 100644 Tests/CMakeLib/testCTestResourceSpec_data/spec29.json
 copy Tests/CMakeLib/testCTestResourceSpec_data/{spec6.json => spec30.json} 
(53%)
 copy Tests/CMakeLib/testCTestResourceSpec_data/{spec6.json => spec31.json} 
(50%)
 copy Tests/CMakeLib/testCTestResourceSpec_data/{spec6.json => spec32.json} 
(50%)
 create mode 100644 

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc4-436-gff198efc77

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  ff198efc77e7b2401aa5cc4d7b6b7c91838dde7b (commit)
   via  3d5227e6b654b7c49c3d0cbc633d832104a0a7fe (commit)
   via  b1175431c385cb052769d4575576ebb19b6e594b (commit)
   via  a033bafbe01fcb4654f075955e0b3de7be81b0f7 (commit)
   via  eafce6c2562a76ef33c2258d2fef04aae2b4e6e9 (commit)
   via  4e4327ee3cbcbb083a0a5aa44b8d932728d30d3f (commit)
   via  a64ba0235fbacfe58751c222997bdd74cf973359 (commit)
   via  f9f294f5faf980aa39721e4deb465b2e9dbbbd9a (commit)
  from  8741d9e262a66de86fac6008bbf466dc25f72ec6 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ff198efc77e7b2401aa5cc4d7b6b7c91838dde7b
commit ff198efc77e7b2401aa5cc4d7b6b7c91838dde7b
Merge: 3d5227e6b6 b1175431c3
Author: Brad King 
AuthorDate: Tue Nov 26 14:12:25 2019 +
Commit: Kitware Robot 
CommitDate: Tue Nov 26 09:12:34 2019 -0500

Merge branch 'release-3.16'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3d5227e6b654b7c49c3d0cbc633d832104a0a7fe
commit 3d5227e6b654b7c49c3d0cbc633d832104a0a7fe
Merge: eafce6c256 a033bafbe0
Author: Brad King 
AuthorDate: Tue Nov 26 14:12:25 2019 +
Commit: Kitware Robot 
CommitDate: Tue Nov 26 09:12:34 2019 -0500

Merge topic 'ctest-resource-fixes'

a033bafbe0 Help: Clarify how tests are run if no resource spec file is 
specified
a64ba0235f CTest: Clarify that resource requirements can be split
f9f294f5fa CTest: Add version field to resource spec file

Acked-by: Kitware Robot 
Merge-request: !4080


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eafce6c2562a76ef33c2258d2fef04aae2b4e6e9
commit eafce6c2562a76ef33c2258d2fef04aae2b4e6e9
Merge: 8741d9e262 4e4327ee3c
Author: Brad King 
AuthorDate: Tue Nov 26 09:03:54 2019 -0500
Commit: Brad King 
CommitDate: Tue Nov 26 09:03:54 2019 -0500

Merge branch 'release-3.15'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4e4327ee3cbcbb083a0a5aa44b8d932728d30d3f
commit 4e4327ee3cbcbb083a0a5aa44b8d932728d30d3f
Merge: 61ce9d1769 4b46523d90
Author: Brad King 
AuthorDate: Tue Nov 26 09:03:08 2019 -0500
Commit: Brad King 
CommitDate: Tue Nov 26 09:03:14 2019 -0500

Merge branch 'backport-implicit-includes-extra-CR' into release-3.15

Merge-request: !4088


---

Summary of changes:
 Help/manual/ctest.1.rst| 26 ++
 Help/prop_test/RESOURCE_GROUPS.rst | 16 +
 Source/CTest/cmCTestResourceSpec.cxx   | 26 ++
 Tests/CMakeLib/testCTestResourceGroups.cxx |  3 +++
 Tests/CMakeLib/testCTestResourceSpec.cxx   | 17 ++
 .../CMakeLib/testCTestResourceSpec_data/spec1.json |  4 
 .../testCTestResourceSpec_data/spec10.json |  4 
 .../testCTestResourceSpec_data/spec11.json |  4 
 .../testCTestResourceSpec_data/spec14.json |  4 
 .../testCTestResourceSpec_data/spec15.json |  4 
 .../testCTestResourceSpec_data/spec16.json |  4 
 .../testCTestResourceSpec_data/spec17.json |  4 
 .../testCTestResourceSpec_data/spec18.json |  4 
 .../{spec6.json => spec19.json}|  2 +-
 .../CMakeLib/testCTestResourceSpec_data/spec2.json |  4 
 .../testCTestResourceSpec_data/spec20.json |  8 +++
 .../{spec6.json => spec21.json}|  2 +-
 .../{spec6.json => spec22.json}|  2 +-
 .../testCTestResourceSpec_data/spec23.json |  7 ++
 .../testCTestResourceSpec_data/spec24.json |  7 ++
 .../testCTestResourceSpec_data/spec25.json |  8 +++
 .../testCTestResourceSpec_data/spec26.json |  8 +++
 .../testCTestResourceSpec_data/spec27.json |  8 +++
 .../testCTestResourceSpec_data/spec28.json |  8 +++
 .../testCTestResourceSpec_data/spec29.json |  5 +
 .../CMakeLib/testCTestResourceSpec_data/spec3.json |  4 
 .../{spec6.json => spec30.json}|  2 +-
 .../{spec6.json => spec31.json}|  2 +-
 .../{spec6.json => spec32.json}|  2 +-
 .../testCTestResourceSpec_data/spec33.json |  5 +
 .../testCTestResourceSpec_data/spec34.json |  5 +
 .../{spec6.json => spec35.json}|  2 +-
 .../CMakeLib/testCTestResourceSpec_data/spec4.json |  4 
 .../CMakeLib/testCTestResourceSpec_data/spec5.json |  4 
 

[Cmake-commits] CMake branch, release, updated. v3.16.0-rc4-19-g8db38cfe33

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, release has been updated
   via  8db38cfe3386c463ef40af8520a5df329f9fd596 (commit)
   via  6d84afc7f2fc84f6a02402d63b40d0cce791b821 (commit)
   via  0cb043390b3a78d80e5cf4dbbb47df1ca8c0d993 (commit)
   via  557ceacf820a935bc5eaeb8637de315730dc0db6 (commit)
   via  4b46523d905451ebdcf0ef8476ebe875945b3a62 (commit)
   via  cb8042b0ab1dba815423c6a236412b2adcb2b880 (commit)
   via  43ffd2c35caf1df37e915460c05da04b583577c4 (commit)
   via  2a5e5b25ba4d6eb68dbee29381774562c98e228f (commit)
   via  08173075c185da050f5aa58e4bd9b5fa6659c63e (commit)
   via  83dbef11352c0075bf0c6c504f0094457b352051 (commit)
   via  881bca249defc148bc98d3caa9799f34536dd256 (commit)
   via  dec3e9363e2ced84ef4c3a3972272c27d90a8766 (commit)
   via  ac1a1bf18bd3d395fd17eddbc5a38e710e737664 (commit)
  from  99f0881d8c6d0c435e595c5f9510da776827ee3e (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
---

Summary of changes:
 Modules/CMakeParseImplicitIncludeInfo.cmake |  2 +-
 Modules/FindODBC.cmake  |  2 ++
 Source/cmLocalGenerator.cxx | 29 -
 3 files changed, 19 insertions(+), 14 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc4-428-g8741d9e262

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  8741d9e262a66de86fac6008bbf466dc25f72ec6 (commit)
   via  78a85fd0696e27ada29076fc4d01b5408e5d93c2 (commit)
   via  8db38cfe3386c463ef40af8520a5df329f9fd596 (commit)
   via  6d84afc7f2fc84f6a02402d63b40d0cce791b821 (commit)
   via  101f7ac63df9601048234864d8daf310da22219c (commit)
   via  5c49f82a2d366edfe4cd86b809859fc0e4a3e7b9 (commit)
   via  0cb043390b3a78d80e5cf4dbbb47df1ca8c0d993 (commit)
   via  86356f140f4d4ee542a10f75d3bcf4cd590de900 (commit)
   via  557ceacf820a935bc5eaeb8637de315730dc0db6 (commit)
   via  7525f0ec6c87576a938b64d52e88e5b319f4a319 (commit)
   via  4b46523d905451ebdcf0ef8476ebe875945b3a62 (commit)
   via  cb8042b0ab1dba815423c6a236412b2adcb2b880 (commit)
   via  43ffd2c35caf1df37e915460c05da04b583577c4 (commit)
  from  bb3d82232d06e553dedd430e6d7a1d0d917108dd (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8741d9e262a66de86fac6008bbf466dc25f72ec6
commit 8741d9e262a66de86fac6008bbf466dc25f72ec6
Merge: 78a85fd069 8db38cfe33
Author: Brad King 
AuthorDate: Tue Nov 26 14:02:31 2019 +
Commit: Kitware Robot 
CommitDate: Tue Nov 26 09:02:41 2019 -0500

Merge branch 'release-3.16'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=78a85fd0696e27ada29076fc4d01b5408e5d93c2
commit 78a85fd0696e27ada29076fc4d01b5408e5d93c2
Merge: 101f7ac63d 6d84afc7f2
Author: Brad King 
AuthorDate: Tue Nov 26 14:02:31 2019 +
Commit: Kitware Robot 
CommitDate: Tue Nov 26 09:02:40 2019 -0500

Merge topic 'implicit-includes-extra-CR'

6d84afc7f2 Merge branch 'backport-implicit-includes-extra-CR' into 
implicit-includes-extra-CR
4b46523d90 CMakeParseImplicitIncludeInfo: Remove all CR chars from compiler 
output

Acked-by: Kitware Robot 
Merge-request: !4088


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=101f7ac63df9601048234864d8daf310da22219c
commit 101f7ac63df9601048234864d8daf310da22219c
Merge: 5c49f82a2d 0cb043390b
Author: Brad King 
AuthorDate: Tue Nov 26 13:55:26 2019 +
Commit: Kitware Robot 
CommitDate: Tue Nov 26 08:56:33 2019 -0500

Merge branch 'release-3.16'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5c49f82a2d366edfe4cd86b809859fc0e4a3e7b9
commit 5c49f82a2d366edfe4cd86b809859fc0e4a3e7b9
Merge: 86356f140f cb8042b0ab
Author: Brad King 
AuthorDate: Tue Nov 26 13:55:26 2019 +
Commit: Kitware Robot 
CommitDate: Tue Nov 26 08:56:33 2019 -0500

Merge topic 'FindODBC-mingw'

cb8042b0ab FindODBC: Add library name for MinGW toolchains

Acked-by: Kitware Robot 
Merge-request: !4076


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=86356f140f4d4ee542a10f75d3bcf4cd590de900
commit 86356f140f4d4ee542a10f75d3bcf4cd590de900
Merge: 7525f0ec6c 557ceacf82
Author: Brad King 
AuthorDate: Tue Nov 26 13:54:54 2019 +
Commit: Kitware Robot 
CommitDate: Tue Nov 26 08:55:09 2019 -0500

Merge branch 'release-3.16'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7525f0ec6c87576a938b64d52e88e5b319f4a319
commit 7525f0ec6c87576a938b64d52e88e5b319f4a319
Merge: bb3d82232d 43ffd2c35c
Author: Brad King 
AuthorDate: Tue Nov 26 13:54:54 2019 +
Commit: Kitware Robot 
CommitDate: Tue Nov 26 08:55:09 2019 -0500

Merge topic 'unity-no-duplicate-path'

43ffd2c35c Unity: No repeated path for internal generated unity files

Acked-by: Kitware Robot 
Merge-request: !4077


---

Summary of changes:
 Modules/CMakeParseImplicitIncludeInfo.cmake |  2 +-
 Modules/FindODBC.cmake  |  2 ++
 Source/cmLocalGenerator.cxx | 29 -
 3 files changed, 19 insertions(+), 14 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc4-415-gbb3d82232d

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  bb3d82232d06e553dedd430e6d7a1d0d917108dd (commit)
  from  e17934c1834ef249107ba5fd46d5e6c2c9017534 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bb3d82232d06e553dedd430e6d7a1d0d917108dd
commit bb3d82232d06e553dedd430e6d7a1d0d917108dd
Author: Kitware Robot 
AuthorDate: Tue Nov 26 00:01:10 2019 -0500
Commit: Kitware Robot 
CommitDate: Tue Nov 26 00:01:10 2019 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index d8e44f686d..249727851b 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191125)
+set(CMake_VERSION_PATCH 20191126)
 #set(CMake_VERSION_RC 0)
 set(CMake_VERSION_IS_DIRTY 0)
 

---

Summary of changes:
 Source/CMakeVersion.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc4-414-ge17934c183

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  e17934c1834ef249107ba5fd46d5e6c2c9017534 (commit)
   via  5129e97285339ad0a481ffdd148bb9e09848a2f4 (commit)
  from  58da842063cc80e34ce3ae16aa8c5fb16cdc29dd (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e17934c1834ef249107ba5fd46d5e6c2c9017534
commit e17934c1834ef249107ba5fd46d5e6c2c9017534
Merge: 58da842063 5129e97285
Author: Brad King 
AuthorDate: Mon Nov 25 15:52:55 2019 +
Commit: Kitware Robot 
CommitDate: Mon Nov 25 10:53:13 2019 -0500

Merge topic 'git-var'

5129e97285 setup-user: switch to git-var to check if username and e-mail 
are set

Acked-by: Kitware Robot 
Merge-request: !4084


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5129e97285339ad0a481ffdd148bb9e09848a2f4
commit 5129e97285339ad0a481ffdd148bb9e09848a2f4
Author: Arkadiusz Drabczyk 
AuthorDate: Sun Nov 24 19:10:56 2019 +0100
Commit: Arkadiusz Drabczyk 
CommitDate: Sun Nov 24 19:10:56 2019 +0100

setup-user: switch to git-var to check if username and e-mail are set

In git, apart from setting username and e-mail in .gitconfig it's also
possible to set username in /etc/passwd and set e-mail using EMAIL
environment variable.  The advantage of this method is that other
programs such as mutt or doxygen will pick up these settings up so
there is no need to set them separately in each program.  Current way
of checking if username and e-mail are set using git config results in
failure if they are set using this method.

diff --git a/Utilities/GitSetup/setup-user b/Utilities/GitSetup/setup-user
index 1af439c45e..0b98879491 100755
--- a/Utilities/GitSetup/setup-user
+++ b/Utilities/GitSetup/setup-user
@@ -20,12 +20,12 @@
 # Project configuration instructions: NONE
 
 for (( ; ; )); do
-   user_name=$(git config user.name || echo '') &&
-   user_email=$(git config user.email || echo '') &&
-   if test -n "$user_name" -a -n "$user_email"; then
+   ident="$(git var GIT_AUTHOR_IDENT 2>/dev/null | rev | cut -d' ' -f3- | 
rev)"
+
+   if test -n "$ident"; then
echo 'Your commits will record as Author:
 
-  '"$user_name <$user_email>"'
+  '"$ident"'
 ' &&
read -ep 'Is the author name and email address above correct? 
[Y/n] ' correct &&
if test "$correct" != "n" -a "$correct" != "N"; then

---

Summary of changes:
 Utilities/GitSetup/setup-user | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.16.0-rc4-412-g58da842063

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  58da842063cc80e34ce3ae16aa8c5fb16cdc29dd (commit)
   via  db3d3ab4fbc24d2e2140e861e101c5f6a5b7303b (commit)
   via  99f0881d8c6d0c435e595c5f9510da776827ee3e (commit)
   via  a5bb08a8c0eee06b7ec0b058266d8436f868f119 (commit)
  from  ae2c2f1f1b5c81ea90579b605a61e9ae96b3178b (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=58da842063cc80e34ce3ae16aa8c5fb16cdc29dd
commit 58da842063cc80e34ce3ae16aa8c5fb16cdc29dd
Merge: db3d3ab4fb 99f0881d8c
Author: Brad King 
AuthorDate: Mon Nov 25 14:37:57 2019 +
Commit: Kitware Robot 
CommitDate: Mon Nov 25 09:38:08 2019 -0500

Merge branch 'release-3.16'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=db3d3ab4fbc24d2e2140e861e101c5f6a5b7303b
commit db3d3ab4fbc24d2e2140e861e101c5f6a5b7303b
Merge: ae2c2f1f1b a5bb08a8c0
Author: Brad King 
AuthorDate: Mon Nov 25 14:37:57 2019 +
Commit: Kitware Robot 
CommitDate: Mon Nov 25 09:38:07 2019 -0500

Merge topic 'FindwxWidgets-rel-and-dbg'

a5bb08a8c0 FindwxWidgets: Fix finding both release and debug libs

Acked-by: Kitware Robot 
Merge-request: !4079


---

Summary of changes:
 Modules/FindwxWidgets.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, release, updated. v3.16.0-rc4-6-g99f0881d8c

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, release has been updated
   via  99f0881d8c6d0c435e595c5f9510da776827ee3e (commit)
   via  a5bb08a8c0eee06b7ec0b058266d8436f868f119 (commit)
  from  602f2118b083f998cd7523efcdd5f39689eb15ac (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
---

Summary of changes:
 Modules/FindwxWidgets.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits