Re: [CMake] How should config packages handle components?

[Robert Dailey]

In the case where I'm exporting 1 target.cmake script per component
for a single package, could someone provide an example on how to
manage dependencies? There are 2 types of dependencies:

1. Dependencies on external packages
2. Cross-dependencies within the same package (i.e. on other
components in the same package)

The cmake-packages doc kind of goes over #1, but #2 doesn't seem to
have examples.

On Fri, Sep 1, 2017 at 1:21 PM, Robert Dailey  wrote:
> First of all, I want to apologize for including the developer list.
> Maybe I'm not being patient enough, but it seems like every post I've
> made on the normal users list doesn't get any attention.
>
> Secondly, the cmake-packages portion of the cmake documentation
> doesn't go into a ton of detail about components, but it does give an
> example towards the bottom of how you export targets for components.
> This leads to my questions:
>
> When defining the target exports via install(TARGET foo EXPORT
> foo-export), is it recommended for all components to collectively
> export as 1 target.cmake script? Or is it better to have 1
> target.cmake script per component? If we use Boost as an example, the
> latter would mean having:
>
> boost-config.cmake
> boost-target-filesystem.cmake
> boost-target-thread.cmake
> ...etc...
>
> This means that boost-config.cmake would "include()" only the relevant
> target cmake scripts based on the provided COMPONENTS list, I assume?
>
> Which is the better approach here and why?
>
> One problem I thought of with the former (one big target.cmake with
> all import targets in there) is that if you only ask for a subset of
> components in find_package(), you will still get all of them since all
> imports are defined in a single file. Does this go against any design
> principles? Assuming this really happens, are there any negative side
> effects?
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [cmake-developers] How should config packages handle components?

[Robert Dailey]

In the case where I'm exporting 1 target.cmake script per component
for a single package, could someone provide an example on how to
manage dependencies? There are 2 types of dependencies:

1. Dependencies on external packages
2. Cross-dependencies within the same package (i.e. on other
components in the same package)

The cmake-packages doc kind of goes over #1, but #2 doesn't seem to
have examples.

On Fri, Sep 1, 2017 at 1:21 PM, Robert Dailey  wrote:
> First of all, I want to apologize for including the developer list.
> Maybe I'm not being patient enough, but it seems like every post I've
> made on the normal users list doesn't get any attention.
>
> Secondly, the cmake-packages portion of the cmake documentation
> doesn't go into a ton of detail about components, but it does give an
> example towards the bottom of how you export targets for components.
> This leads to my questions:
>
> When defining the target exports via install(TARGET foo EXPORT
> foo-export), is it recommended for all components to collectively
> export as 1 target.cmake script? Or is it better to have 1
> target.cmake script per component? If we use Boost as an example, the
> latter would mean having:
>
> boost-config.cmake
> boost-target-filesystem.cmake
> boost-target-thread.cmake
> ...etc...
>
> This means that boost-config.cmake would "include()" only the relevant
> target cmake scripts based on the provided COMPONENTS list, I assume?
>
> Which is the better approach here and why?
>
> One problem I thought of with the former (one big target.cmake with
> all import targets in there) is that if you only ask for a subset of
> components in find_package(), you will still get all of them since all
> imports are defined in a single file. Does this go against any design
> principles? Assuming this really happens, are there any negative side
> effects?
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [CMake] Adding compile and build type tests to CMake/CTest

[Edward Diener]

On 9/5/2017 2:47 AM, Dvir Yitzchaki wrote:

There's already CheckCXXSourceCompiles and friends.
The only problem is that try_compile is not scriptable otherwise you could let 
the test invoke
${CMAKE_COMMAND} -P check_source_compiles.cmake.


To put it succinctly CMake should adding compile-time testing so that 
when some compilation succeeds the test is successful and if the 
compilation fails the test is not successful, with the proviso that you 
can reverse the result as a compile should fail type of test. Similarly 
a build type testing, without having to run anything should be added 
along the same lines.


In modern C++ it is perfectly feasible, especially with template 
programming, to do compile time testing, invoking a compile-time static 
assert as a compile-time failure. Boost has had this for years and 
modern C++ has it as part of the latest version of the C++ standard. 
CMake needs to update itself to the reality that pure compile-time 
testing is a reality for modern C++ and should update itself 
accordingly. Only having run-time testing is an artifact of the past. 
Hopefully CMake developers will get the message and make the necessary 
update to CMake/CTest.




-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Roger Leigh
Sent: Monday, September 4, 2017 16:51
To: cmake@cmake.org
Subject: Re: [CMake] Adding compile and build type tests to CMake/CTest

On 04/09/17 14:40, Edward Diener wrote:

Boost Build has tests for running an application successfully or not,
for compiling one or more source files successfully or not, and for
building one or more source files into an exe or not. These tests in
Boost Build are the run/run-fail, compile/compile-fail, and
link/link-fail rules.

CMake/CTest has the exact equivalent to the run/run-fail rule in its
add_test framework, but there is not add_test equivalent to the other
two sets of rules. It sure would be nice, when Boost transitions to
using CMake/CTest instead of Boost Build, if CMake/CTest had the
equivalent of the other two sets of types of test in its add_test
framework.

Is there any consensus that these other two types of tests might be
valuable for CMake/CTest, or any way to make this happen ?


I've certainly wished for them.  Particularly when testing templated code where 
you want to test that certain things fail correctly, e.g. via static_assert or 
simply being invalid.

I understand it's possible to make this work partially, by creating targets 
which aren't built by default, and then add tests which invoke the targets.  
But this appears to have some caveats, such as potential misbehaviour with 
parallel testing.  Or you can have a separate CMake build for each individual 
target, but it's extra complexity.  Having a proper means of registering such 
tests would be very, very nice.


Regards,
Roger




--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Adding compile and build type tests to CMake/CTest

[Edward Diener]

On 9/4/2017 9:51 AM, Roger Leigh wrote:

On 04/09/17 14:40, Edward Diener wrote:
Boost Build has tests for running an application successfully or not, 
for compiling one or more source files successfully or not, and for 
building one or more source files into an exe or not. These tests in 
Boost Build are the run/run-fail, compile/compile-fail, and 
link/link-fail rules.


CMake/CTest has the exact equivalent to the run/run-fail rule in its 
add_test framework, but there is not add_test equivalent to the other 
two sets of rules. It sure would be nice, when Boost transitions to 
using CMake/CTest instead of Boost Build, if CMake/CTest had the 
equivalent of the other two sets of types of test in its add_test 
framework.


Is there any consensus that these other two types of tests might be 
valuable for CMake/CTest, or any way to make this happen ?


I've certainly wished for them.  Particularly when testing templated 
code where you want to test that certain things fail correctly, e.g. via 
static_assert or simply being invalid.


I think that CMake has missed out on the simple fact that in modern C++ 
you can create compile-time tests/asserts rather than rely on run-time 
tests. In other words CMake has no provision for compile-time testing, 
only run-time testing. In this respect CMake is definitely behind the 
curve of modern C++ development. Of course unless the CMake developers 
wake up to this simple fact, and plan to provide compile-time testing, 
and possibly even build testing, ala Boost Build, to CMake it will 
remain behind the curve for modern C++ development.


When the Boost Steering Committee decided to move Boost to using CMake 
in the near future, it may not have taken into account the fact that 
CMake might be missing something that modern C++ development in Boost 
uses via Boost Build. Unless there is some sort of push back to the 
CMake developers so that the needed functionality is added to CMake, it 
is going to be a long, hard road for converting from Boost Build to 
CMake for the Boost library and tools. This is not a knock against 
CMake, which is widely used and widely popular, but rather a recognition 
that Boost uses modern C++ and CMake may not provide all the 
building/testing facilities needed for a modern C++ development 
environment such as Boost.




I understand it's possible to make this work partially, by creating 
targets which aren't built by default, and then add tests which invoke 
the targets.  But this appears to have some caveats, such as potential 
misbehaviour with parallel testing.  Or you can have a separate CMake 
build for each individual target, but it's extra complexity.  Having a 
proper means of registering such tests would be very, very nice.



Regards,
Roger



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Should configuration package files define module package variables?

[Robert Dailey]

On Sat, Sep 2, 2017 at 3:08 AM, P F  wrote:
> In general, if the library does not have any dependencies, you can just 
> export the targets directly to the config.cmake file:
>
> install(TARGETS foo EXPORT foo-config)
> install(EXPORT foo-config DESTINATION lib/cmake/foo)
>
> However, if the library has dependencies, you will need to iterate over them 
> in the config.cmake file. That is if `foo` uses zlib, like this:
>
> find_package(ZLIB)
> target_link_libraries(foo ZLIB::ZLIB)
>
> Then the foo-config.cmake needs to do this(assuming the export targets are 
> written to foo-targets):
>
> include(CMakeFindDependencyMacro)
> find_dependency(ZLIB)
> include("${CMAKE_CURRENT_LIST_DIR}/foo-targets.cmake”)
>
> The reason for this is that the imported foo target will link against 
> ZLIB::ZLIB, but it will not define it. Actually, the generated 
> foo-targets.cmake will create an error if ZLIB::ZLIB doesn’t exists, which is 
> why `find_dependency(ZLIB)`(which is really just `find_package` underneath) 
> needs to be called before including the foo-targets.cmake.

When you throw components in the mix, where you have 1 targets.cmake
exported per component, each may have its own find_dependency()
requirements. It would be nice if that was self-contained in the
targets.cmake script itself, but there's no examples I could find on
how to manage per-component find dependencies like this, especially if
those components are put into `OPTIONAL_COMPONENTS`.

Thanks for the information, it is very helpful!
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [cmake-developers] [CMake] Should configuration package files define module package variables?

[Robert Dailey]

On Sat, Sep 2, 2017 at 3:08 AM, P F  wrote:
> In general, if the library does not have any dependencies, you can just 
> export the targets directly to the config.cmake file:
>
> install(TARGETS foo EXPORT foo-config)
> install(EXPORT foo-config DESTINATION lib/cmake/foo)
>
> However, if the library has dependencies, you will need to iterate over them 
> in the config.cmake file. That is if `foo` uses zlib, like this:
>
> find_package(ZLIB)
> target_link_libraries(foo ZLIB::ZLIB)
>
> Then the foo-config.cmake needs to do this(assuming the export targets are 
> written to foo-targets):
>
> include(CMakeFindDependencyMacro)
> find_dependency(ZLIB)
> include("${CMAKE_CURRENT_LIST_DIR}/foo-targets.cmake”)
>
> The reason for this is that the imported foo target will link against 
> ZLIB::ZLIB, but it will not define it. Actually, the generated 
> foo-targets.cmake will create an error if ZLIB::ZLIB doesn’t exists, which is 
> why `find_dependency(ZLIB)`(which is really just `find_package` underneath) 
> needs to be called before including the foo-targets.cmake.

When you throw components in the mix, where you have 1 targets.cmake
exported per component, each may have its own find_dependency()
requirements. It would be nice if that was self-contained in the
targets.cmake script itself, but there's no examples I could find on
how to manage per-component find dependencies like this, especially if
those components are put into `OPTIONAL_COMPONENTS`.

Thanks for the information, it is very helpful!
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Cmake-commits] CMake branch, master, updated. v3.9.1-720-g20e5f7a

[Kitware Robot]

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  20e5f7a9c97b5311bda969062c659858c9c896c8 (commit)
   via  4defa6c21c0a483db229eb1ddbcbe17002722b21 (commit)
   via  e7de2a7def5d70b00df16039f9ce180b53fc86f1 (commit)
   via  1561748496b10bc74adc731fd1d5e7c733034cba (commit)
   via  2645cb6208ff62cd64deb9862e3eb4d1a81264b3 (commit)
   via  cbf201782205d3e3c7fda33bb1f5828ac13efa1e (commit)
   via  37760743fc50d9ad864e8a83f0da75ab000c22ec (commit)
  from  ad1b9eba85ddb5bc51f862b4001bab666ddb (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=20e5f7a9c97b5311bda969062c659858c9c896c8
commit 20e5f7a9c97b5311bda969062c659858c9c896c8
Merge: 4defa6c 1561748
Author: Brad King 
AuthorDate: Tue Sep 5 13:30:58 2017 +
Commit: Kitware Robot 
CommitDate: Tue Sep 5 09:31:06 2017 -0400

Merge topic 'ExternalProject-command'

15617484 ExternalProject: Prevent COMMAND from being treated as a true 
keyword

Acked-by: Kitware Robot 
Merge-request: !1178


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4defa6c21c0a483db229eb1ddbcbe17002722b21
commit 4defa6c21c0a483db229eb1ddbcbe17002722b21
Merge: e7de2a7 2645cb6
Author: Brad King 
AuthorDate: Tue Sep 5 13:28:35 2017 +
Commit: Kitware Robot 
CommitDate: Tue Sep 5 09:28:40 2017 -0400

Merge topic 'add-FindPatch-module'

2645cb62 FindPatch: Add module to find 'patch' command-line tool

Acked-by: Kitware Robot 
Merge-request: !1184


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e7de2a7def5d70b00df16039f9ce180b53fc86f1
commit e7de2a7def5d70b00df16039f9ce180b53fc86f1
Merge: ad1b9eb cbf2017
Author: Brad King 
AuthorDate: Tue Sep 5 13:27:19 2017 +
Commit: Kitware Robot 
CommitDate: Tue Sep 5 09:27:22 2017 -0400

Merge topic 'update-kwsys'

cbf20178 Merge branch 'upstream-KWSys' into update-kwsys
37760743 KWSys 2017-09-01 (aee0cf59)

Acked-by: Kitware Robot 
Merge-request: !1223


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1561748496b10bc74adc731fd1d5e7c733034cba
commit 1561748496b10bc74adc731fd1d5e7c733034cba
Author: Craig Scott 
AuthorDate: Wed Aug 23 22:40:49 2017 +0800
Commit: Craig Scott 
CommitDate: Sat Sep 2 17:53:16 2017 +1000

ExternalProject: Prevent COMMAND from being treated as a true keyword

The known keywords for each function are obtained by scraping the
documentation for lines matching a particular regular expression. In
commit 8842a027 (ExternalProject: Improve documentation, 2017-07-09),
the docs were overhauled and the COMMAND docs subsequently matched the
regular expression when they shouldn't have. This made COMMAND appear as
a true keyword, which thwarted the special handling logic elsewhere for
the intended use of COMMAND arguments.

This commit contains a workaround for issue #17229 to force a dependency
of the patch step on the update step to ensure a predictable step order.

Fixes: #17198

diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index d92eb5f..912c5ac 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -870,6 +870,14 @@ foreach(line IN LISTS lines)
 set(_ep_keyword_sep)
   elseif("${line}" MATCHES "^ +``([A-Z0-9_]+) [^`]*``$")
 set(_ep_key "${CMAKE_MATCH_1}")
+# COMMAND should never be included as a keyword,
+# for ExternalProject_Add(), as it is treated as a
+# special case by argument parsing as an extension
+# of a previous ..._COMMAND
+if("x${_ep_key}x" STREQUAL "xCOMMANDx" AND
+   "x${_ep_func}x" STREQUAL "xExternalProject_Addx")
+  continue()
+endif()
 #message("  keyword [${_ep_key}]")
 string(APPEND _ep_keywords_${_ep_func}
   "${_ep_keyword_sep}${_ep_key}")
diff --git a/Tests/RunCMake/ExternalProject/MultiCommand-build-stdout.txt 
b/Tests/RunCMake/ExternalProject/MultiCommand-build-stdout.txt
new file mode 100644
index 000..30ebc7d
--- /dev/null
+++ b/Tests/RunCMake/ExternalProject/MultiCommand-build-stdout.txt
@@ -0,0 +1,15 @@
+.* *download 1
+.* *download 2
+.* *update 1
+.* *update 2
+.* *patch 1
+.* *patch 2
+.* *configure 1
+.* *configure 2
+.* *build 1
+.* *build 2
+.* *install 1
+.* *install 2
+.* *test 1
+.* *test 2
+.*
diff --git 

Re: [cmake-developers] CMake PCH Prototype

[Ben Boeckel]

On Sat, Sep 02, 2017 at 12:15:28 +0200, Máté Ferenc Nagy-Egri via 
cmake-developers wrote:
> Do I understand correctly, that this work is not going to be
> mainlined? I was very much hoping it would.

Development stalled. We close MRs which need work and haven't been
actively developed in order to keep the MR queue free of stalled work
(that is what `workflow:expired` indicates). When work is ready to
continue, it can be reopened.

--Ben
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [CMake] CMake Coverage broken with Ninja

[Brad King]

On 09/05/2017 07:42 AM, Gerhard Gappmeier wrote:
> Could you already verify if this problem is also the cause for the
> coverage issue?

I tried your example in a fully out-of-source build (where the
build tree is not inside the source tree), and coverage works.

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CMake Coverage broken with Ninja

[Gerhard Gappmeier]

Hi Brad,

thanks for that information.
It is great to see that you are working on this.

Could you already verify if this problem is also the cause for the
coverage issue?

On 09/05/2017 01:31 PM, Brad King wrote:
> On 09/02/2017 03:14 AM, Gerhard Gappmeier wrote:
>> This is quite annoying, inconsistent with Makefiles and was already
>> reported once here: https://cmake.org/Bug/print_bug_page.php?bug_id=13894
>> AFAIK this was never fixed.
> Discussion of that issue is now here:
>
>   https://gitlab.kitware.com/cmake/cmake/issues/13894
>
> We made a serious attempt to fix it, but ran into a major problem
> described here:
>
>   https://gitlab.kitware.com/cmake/cmake/issues/13894#note_233789
>
> Fixing it requires a feature in Ninja:
>
>   https://github.com/ninja-build/ninja/issues/1251
>
> I posted a proposal to their list about it but got no response:
>
>   https://groups.google.com/forum/#!topic/ninja-build/yJvs7u0n2iA
>
> ---
>
> One may use out-of-source builds to get absolute paths to the files
> in the main source tree.
>
> -Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CMake Coverage broken with Ninja

[Brad King]

On 09/02/2017 03:14 AM, Gerhard Gappmeier wrote:
> This is quite annoying, inconsistent with Makefiles and was already
> reported once here: https://cmake.org/Bug/print_bug_page.php?bug_id=13894
> AFAIK this was never fixed.

Discussion of that issue is now here:

  https://gitlab.kitware.com/cmake/cmake/issues/13894

We made a serious attempt to fix it, but ran into a major problem
described here:

  https://gitlab.kitware.com/cmake/cmake/issues/13894#note_233789

Fixing it requires a feature in Ninja:

  https://github.com/ninja-build/ninja/issues/1251

I posted a proposal to their list about it but got no response:

  https://groups.google.com/forum/#!topic/ninja-build/yJvs7u0n2iA

---

One may use out-of-source builds to get absolute paths to the files
in the main source tree.

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Path to vc_redist

[Roman Wüger]

Thank you Robert,

I came up with the following, maybe someone has a better idea:

if (WIN32)
if(CMAKE_SIZEOF_VOID_P EQUAL 8) # 64-bit
set(REDIST_ARCH x64)
else()
set(REDIST_ARCH x86)
endif()
 
set(REDIST_FILE vcredist_${REDIST_ARCH}.exe)
 
set(CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP TRUE)
include(InstallRequiredSystemLibraries)
 
# Check if the list contains minimum one element, to get the path from
list(LENGTHCMAKE_INSTALL_SYSTEM_RUNTIME_LIBS libsCount)
if (libsCount GREATER 0)
list(GET CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS 0 _path)
 
get_filename_component(_path ${_path} DIRECTORY)
get_filename_component(_path ${_path}/../../ ABSOLUTE)
 
if (EXISTS "${_path}/${REDIST_FILE}") # VS 2017
set(REDIST_FILE ${_path}/${REDIST_FILE})
else()
get_filename_component(_path ${_path}/1033ABSOLUTE)
set(REDIST_FILE ${_path}/${REDIST_FILE})
endif()
 
install(PROGRAMS ${_path}/${REDIST_FILE})
endif()
endif()
 
Regards
Roman

> Am 04.09.2017 um 15:20 schrieb Robert Maynard :
> 
> You can use the InstallRequiredSystemLibraries to do this. Since it sounds 
> like you don't want all the libraries installed, use 
> CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP and than deduce the path of 
> vc_redist.exe from the value(s) in CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS.
> 
>> On Mon, Sep 4, 2017 at 3:01 AM, Roman Wüger  wrote:
>> Hello,
>> 
>> is there already an existing function to get the vc_redist.exe for the 
>> current generator?
>> 
>> Regards
>> Roman
>> --
>> 
>> Powered by www.kitware.com
>> 
>> Please keep messages on-topic and check the CMake FAQ at: 
>> http://www.cmake.org/Wiki/CMake_FAQ
>> 
>> Kitware offers various services to support the CMake community. For more 
>> information on each offering, please visit:
>> 
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>> 
>> Visit other Kitware open-source projects at 
>> http://www.kitware.com/opensource/opensource.html
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
> 
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [cmake-developers] [CMake] Path to vc_redist

[Roman Wüger]

Thank you Robert,

I came up with the following, maybe someone has a better idea:

if (WIN32)
if(CMAKE_SIZEOF_VOID_P EQUAL 8) # 64-bit
set(REDIST_ARCH x64)
else()
set(REDIST_ARCH x86)
endif()
 
set(REDIST_FILE vcredist_${REDIST_ARCH}.exe)
 
set(CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP TRUE)
include(InstallRequiredSystemLibraries)
 
# Check if the list contains minimum one element, to get the path from
list(LENGTHCMAKE_INSTALL_SYSTEM_RUNTIME_LIBS libsCount)
if (libsCount GREATER 0)
list(GET CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS 0 _path)
 
get_filename_component(_path ${_path} DIRECTORY)
get_filename_component(_path ${_path}/../../ ABSOLUTE)
 
if (EXISTS "${_path}/${REDIST_FILE}") # VS 2017
set(REDIST_FILE ${_path}/${REDIST_FILE})
else()
get_filename_component(_path ${_path}/1033ABSOLUTE)
set(REDIST_FILE ${_path}/${REDIST_FILE})
endif()
 
install(PROGRAMS ${_path}/${REDIST_FILE})
endif()
endif()
 
Regards
Roman

> Am 04.09.2017 um 15:20 schrieb Robert Maynard :
> 
> You can use the InstallRequiredSystemLibraries to do this. Since it sounds 
> like you don't want all the libraries installed, use 
> CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP and than deduce the path of 
> vc_redist.exe from the value(s) in CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS.
> 
>> On Mon, Sep 4, 2017 at 3:01 AM, Roman Wüger  wrote:
>> Hello,
>> 
>> is there already an existing function to get the vc_redist.exe for the 
>> current generator?
>> 
>> Regards
>> Roman
>> --
>> 
>> Powered by www.kitware.com
>> 
>> Please keep messages on-topic and check the CMake FAQ at: 
>> http://www.cmake.org/Wiki/CMake_FAQ
>> 
>> Kitware offers various services to support the CMake community. For more 
>> information on each offering, please visit:
>> 
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>> 
>> Visit other Kitware open-source projects at 
>> http://www.kitware.com/opensource/opensource.html
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
> 
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [CMake] Adding compile and build type tests to CMake/CTest

[Dvir Yitzchaki]

There's already CheckCXXSourceCompiles and friends. 
The only problem is that try_compile is not scriptable otherwise you could let 
the test invoke 
${CMAKE_COMMAND} -P check_source_compiles.cmake.

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Roger Leigh
Sent: Monday, September 4, 2017 16:51
To: cmake@cmake.org
Subject: Re: [CMake] Adding compile and build type tests to CMake/CTest

On 04/09/17 14:40, Edward Diener wrote:
> Boost Build has tests for running an application successfully or not, 
> for compiling one or more source files successfully or not, and for 
> building one or more source files into an exe or not. These tests in 
> Boost Build are the run/run-fail, compile/compile-fail, and 
> link/link-fail rules.
> 
> CMake/CTest has the exact equivalent to the run/run-fail rule in its 
> add_test framework, but there is not add_test equivalent to the other 
> two sets of rules. It sure would be nice, when Boost transitions to 
> using CMake/CTest instead of Boost Build, if CMake/CTest had the 
> equivalent of the other two sets of types of test in its add_test 
> framework.
> 
> Is there any consensus that these other two types of tests might be 
> valuable for CMake/CTest, or any way to make this happen ?

I've certainly wished for them.  Particularly when testing templated code where 
you want to test that certain things fail correctly, e.g. via static_assert or 
simply being invalid.

I understand it's possible to make this work partially, by creating targets 
which aren't built by default, and then add tests which invoke the targets.  
But this appears to have some caveats, such as potential misbehaviour with 
parallel testing.  Or you can have a separate CMake build for each individual 
target, but it's extra complexity.  Having a proper means of registering such 
tests would be very, very nice.


Regards,
Roger
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake