[Cmake-commits] CMake branch, master, updated. v3.14.0-550-g14b6cd4

[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  14b6cd497f0e27dc5d02d678fcab0ca1492a320b (commit)
  from  07dd1d2782603126e65c57b3a71248dbdf83ed46 (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=14b6cd497f0e27dc5d02d678fcab0ca1492a320b
commit 14b6cd497f0e27dc5d02d678fcab0ca1492a320b
Author: Kitware Robot 
AuthorDate: Thu Mar 28 00:01:07 2019 -0400
Commit: Kitware Robot 
CommitDate: Thu Mar 28 00:01:07 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 1500f07..3ca49f3 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 14)
-set(CMake_VERSION_PATCH 20190327)
+set(CMake_VERSION_PATCH 20190328)
 #set(CMake_VERSION_RC 1)

---

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

Re: [CMake] Install without building unittests

[Scott Bloom]

Note, Im running from inside visual studio...  I do realize for a makefile 
based system, I can run make install from inside the executable's build 
directory

From: CMake  On Behalf Of Scott Bloom
Sent: Wednesday, March 27, 2019 7:23 PM
To: cmake@cmake.org
Subject: [CMake] Install without building unittests

I asked this a couple of years ago, and the answer was "no"...

If you run tests, it doesn't automatically build tests...  So why does an 
install?

I would never release something into the wild with out running the tests...

But, for developer builds, were we need to install all the packages in order to 
run the applications, sometimes I just want to test the GUI which requires an 
install of the core application into the correct location, without building the 
1500+ (yes 1500) unittests, which can take 15-20 minutes to build on their 
own...

Is there anyway to break the dependency??

Scott
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[CMake] Install without building unittests

[Scott Bloom]

I asked this a couple of years ago, and the answer was "no"...

If you run tests, it doesn't automatically build tests...  So why does an 
install?

I would never release something into the wild with out running the tests...

But, for developer builds, were we need to install all the packages in order to 
run the applications, sometimes I just want to test the GUI which requires an 
install of the core application into the correct location, without building the 
1500+ (yes 1500) unittests, which can take 15-20 minutes to build on their 
own...

Is there anyway to break the dependency??

Scott
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] How can I automatically optionally build a submodule?

[Andreas Naumann]

For me, this sounds more like foo is an independent thing and not a
subdirectory.

In this case, I think about two solutions:
    1) Use a macro/function "check_yada", which sets a variable
"yada_usable". If you extract this logic in an extra .cmake file, you
can reuse it in your yada CMakelists.txt
    2) Use foo as an external project. But thats looks like a major
change in the project structure.


Am 27.03.19 um 20:05 schrieb Steve Keller:

"Albrecht Schlosser"  wrote:


If you want yadda to be optional then don't use REQUIRED.

find_package(yadda)
if (yadda_FOUND)
message(STATUS "found yadda, building bar ...")

# add your code to build bar here

endif ()

This should do what you want - unless I misunderstood your question.

This will roughly do what I want, but I think it does not correctly
express things.  For the sub-project, yadda is not optional, and if I
call cmake in that sub-project's directory, it should fail.

What I think would be appropriate would be a command
add_subdirectory_optional(...) or add_subdirectory_and_ignore_errors(...)
or something similar.

Steve



--

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] How can I automatically optionally build a submodule?

[Steve Keller]

"Simon Richter"  wrote:

> With my Debian Developer hat on: please also add a mechanism to manually
> specify whether the optional component should be built. If the
> dependency changes and suddenly a component goes missing without
> triggering a build failure, that can be rather annoying for users.
>
> Without a package system, this also means that old files may stick
> around after installation, so your program should be aware that
> installed plugins could be built against an older API and weren't
> updated during the last install run.

I'd like to do that if I'd know how to achieve that using cmake.  But I find
cmake is much too large and is incapable of many things I'd expect from
a build system tool.  It also makes development ugly for the Unix accustomed
developer, only to make things portable to Windows, which I don't want anyway.

Currently, we have a shell script wrapper around cmake that does something like

if [  ]; then
BUILD_FOO=true
else
BUILD_FOO=false
fi

and in CMakeLists.txt

set(BUILD_FOO "true" CACHE BOOL "description")
...
if (BUILD_FOO)
add_subdirectory(foo)
endif()

This is *ugly* but I don't know how to do this in cmake.

Steve
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] How can I automatically optionally build a submodule?

[Steve Keller]

"Albrecht Schlosser"  wrote:

> If you want yadda to be optional then don't use REQUIRED.
>
> find_package(yadda)
> if (yadda_FOUND)
>message(STATUS "found yadda, building bar ...")
>
># add your code to build bar here
>
> endif ()
>
> This should do what you want - unless I misunderstood your question.

This will roughly do what I want, but I think it does not correctly
express things.  For the sub-project, yadda is not optional, and if I
call cmake in that sub-project's directory, it should fail.

What I think would be appropriate would be a command
add_subdirectory_optional(...) or add_subdirectory_and_ignore_errors(...)
or something similar.

Steve
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, master, updated. v3.14.0-549-g07dd1d2

[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  07dd1d2782603126e65c57b3a71248dbdf83ed46 (commit)
   via  97c163f5f7bd9c056b6ca0dd03f1b239ff61764b (commit)
   via  9cf64bb10141b3ef2453690861277f11e0cdff5f (commit)
   via  505bdd3d2982d4712301fe3416f546e46fa72eae (commit)
  from  a60f1c4faf32e0e1d89a4f88e3b5851e1c0aec27 (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=07dd1d2782603126e65c57b3a71248dbdf83ed46
commit 07dd1d2782603126e65c57b3a71248dbdf83ed46
Merge: a60f1c4 97c163f
Author: Brad King 
AuthorDate: Wed Mar 27 14:21:51 2019 -0400
Commit: Brad King 
CommitDate: Wed Mar 27 14:21:51 2019 -0400

Merge branch 'release-3.14'


---

Summary of changes:


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.14.0-20-g97c163f

[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  97c163f5f7bd9c056b6ca0dd03f1b239ff61764b (commit)
   via  9cf64bb10141b3ef2453690861277f11e0cdff5f (commit)
   via  a3a1e69f8a8e6571bbb8c9257b401f04c22bd1e2 (commit)
   via  1d16eae868b2542789de9d2b6224c8d3185540d4 (commit)
   via  505bdd3d2982d4712301fe3416f546e46fa72eae (commit)
   via  b127e0c5610221d10c1d6658db96741ab85a083c (commit)
  from  c22a2b49afed255593d1cc8425a5fd1fd2e1a81c (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/release/3.14.rst| 14 
 Modules/CMakeDetermineCUDACompiler.cmake |  5 +++
 Modules/FindFontconfig.cmake | 56 
 Modules/FindX11.cmake|  2 +-
 Source/CTest/cmParseJacocoCoverage.cxx   |  1 +
 Tests/FindFontconfig/Test/CMakeLists.txt |  6 ++--
 6 files changed, 52 insertions(+), 32 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.14.0-545-ga60f1c4

[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  a60f1c4faf32e0e1d89a4f88e3b5851e1c0aec27 (commit)
   via  c03ee3ca714715671ff54cd2f61217b62637ff14 (commit)
   via  a3a1e69f8a8e6571bbb8c9257b401f04c22bd1e2 (commit)
   via  1d16eae868b2542789de9d2b6224c8d3185540d4 (commit)
  from  c126e80b5a7a9cf98ebea7c34a2b5b5f848dfab1 (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=a60f1c4faf32e0e1d89a4f88e3b5851e1c0aec27
commit a60f1c4faf32e0e1d89a4f88e3b5851e1c0aec27
Merge: c03ee3c 1d16eae
Author: Brad King 
AuthorDate: Wed Mar 27 18:11:37 2019 +
Commit: Kitware Robot 
CommitDate: Wed Mar 27 14:11:57 2019 -0400

Merge topic 'jacoco_parser_crash'

1d16eae868 ctest_coverage: fix out-of-bounds index in Jacoco parser

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c03ee3ca714715671ff54cd2f61217b62637ff14
commit c03ee3ca714715671ff54cd2f61217b62637ff14
Merge: c126e80 a3a1e69
Author: Brad King 
AuthorDate: Wed Mar 27 18:11:01 2019 +
Commit: Kitware Robot 
CommitDate: Wed Mar 27 14:11:08 2019 -0400

Merge topic 'FindFontconfig-var-case'

a3a1e69f8a FindFontconfig: Convert module variables to camel case

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3a1e69f8a8e6571bbb8c9257b401f04c22bd1e2
commit a3a1e69f8a8e6571bbb8c9257b401f04c22bd1e2
Author: Brad King 
AuthorDate: Tue Mar 26 13:44:52 2019 -0400
Commit: Brad King 
CommitDate: Tue Mar 26 14:14:09 2019 -0400

FindFontconfig: Convert module variables to camel case

Our documented standard for find module variable names is to match the
case of the find module package name.  This was overlooked when the
module was added by commit 84e7920b3a (FindFontconfig: Add module to
find Fontconfig, 2018-09-27, v3.14.0-rc1~523^2).

The module was released with the upper case names in CMake 3.14.0, so
fix it to have camel case names in 3.14.1.  This is incompatible but
anyone using a given release series should be using the latest patch on
it and we've made breaking fixups on newly released features like this
before.

Reported-by: Christophe Giboudeaux 
Fixes: #19094

diff --git a/Help/release/3.14.rst b/Help/release/3.14.rst
index 5038a75..f2a91c6 100644
--- a/Help/release/3.14.rst
+++ b/Help/release/3.14.rst
@@ -377,3 +377,17 @@ Other Changes
 * CMake no longer issues a warning if a target listed in an
   :command:`install(TARGETS)` command has its :prop_tgt:`EXCLUDE_FROM_ALL`
   property set to true.
+
+Updates
+===
+
+Changes made since CMake 3.14.0 include the following.
+
+3.14.1
+--
+
+* The :module:`FindFontconfig` module added by 3.14.0 accidentally
+  used uppercase ``FONTCONFIG_*`` variable names that do not match
+  our conventions.  3.14.1 revises the module to use ``Fontconfig_*``
+  variable names.  This is incompatible with 3.14.0 but since the
+  module is new in the 3.14 series usage should not yet be widespread.
diff --git a/Modules/FindFontconfig.cmake b/Modules/FindFontconfig.cmake
index 96e1e76..a6f0180 100644
--- a/Modules/FindFontconfig.cmake
+++ b/Modules/FindFontconfig.cmake
@@ -18,15 +18,15 @@ Result Variables
 
 This will define the following variables in your project:
 
-``FONTCONFIG_FOUND``
+``Fontconfig_FOUND``
   true if (the requested version of) Fontconfig is available.
-``FONTCONFIG_VERSION``
+``Fontconfig_VERSION``
   the version of Fontconfig.
-``FONTCONFIG_LIBRARIES``
+``Fontconfig_LIBRARIES``
   the libraries to link against to use Fontconfig.
-``FONTCONFIG_INCLUDE_DIRS``
+``Fontconfig_INCLUDE_DIRS``
   where to find the Fontconfig headers.
-``FONTCONFIG_COMPILE_OPTIONS``
+``Fontconfig_COMPILE_OPTIONS``
   this should be passed to target_compile_options(), if the
   target is not used for linking
 
@@ -37,10 +37,10 @@ This will define the following variables in your project:
 # in the FIND_PATH() and FIND_LIBRARY() calls
 find_package(PkgConfig QUIET)
 pkg_check_modules(PKG_FONTCONFIG QUIET fontconfig)
-set(FONTCONFIG_COMPILE_OPTIONS ${PKG_FONTCONFIG_CFLAGS_OTHER})
-set(FONTCONFIG_VERSION ${PKG_FONTCONFIG_VERSION})
+set(Fontconfig_COMPILE_OPTIONS ${PKG_FONTCONFIG_CFLAGS_OTHER})
+set(Fontconfig_VERSION ${PKG_FONTCONFIG_VERSION})
 
-find_path( FONTCONFIG_INCLUDE_DIR
+find_path( Fontconfig_INCLUDE_DIR
   NAMES
 fontconfig/fontconfig.h
   HINTS
@@ -48,24 +48,24 @@ find_path( FONTCONFIG_INCLUDE_DIR
 /usr/X11/include
 )
 
-find_library( FONTCONFIG_LIBRARY
+find_library( 

[Cmake-commits] CMake branch, master, updated. v3.14.0-541-gc126e80

[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  c126e80b5a7a9cf98ebea7c34a2b5b5f848dfab1 (commit)
   via  3843d0550bf0657b5626d02c4184350c8f26aff5 (commit)
   via  82dec5191ccfd1308c157075acc53f677a8895de (commit)
   via  b127e0c5610221d10c1d6658db96741ab85a083c (commit)
  from  fcfbc01d68aac2eca7435bfa0f01e5d1b3524303 (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=c126e80b5a7a9cf98ebea7c34a2b5b5f848dfab1
commit c126e80b5a7a9cf98ebea7c34a2b5b5f848dfab1
Merge: 3843d05 b127e0c
Author: Brad King 
AuthorDate: Wed Mar 27 17:58:49 2019 +
Commit: Kitware Robot 
CommitDate: Wed Mar 27 13:59:26 2019 -0400

Merge topic 'cuda-bracket-output'

b127e0c561 CUDA: Tolerate square brackets in PROMPT environment variable

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3843d0550bf0657b5626d02c4184350c8f26aff5
commit 3843d0550bf0657b5626d02c4184350c8f26aff5
Merge: fcfbc01 82dec51
Author: Brad King 
AuthorDate: Wed Mar 27 17:58:30 2019 +
Commit: Kitware Robot 
CommitDate: Wed Mar 27 13:58:38 2019 -0400

Merge topic 'find_dependency-cleanup'

82dec5191c find_dependency: Remove clearing of unused cmake_fd_exact_arg 
variable

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=82dec5191ccfd1308c157075acc53f677a8895de
commit 82dec5191ccfd1308c157075acc53f677a8895de
Author: Damien R <9464-damie...@users.noreply.gitlab.kitware.com>
AuthorDate: Tue Mar 26 14:17:19 2019 +0100
Commit: Brad King 
CommitDate: Tue Mar 26 11:56:02 2019 -0400

find_dependency: Remove clearing of unused cmake_fd_exact_arg variable

The variable is unused since commit ab358d6a85 (Improve find_dependency
argument handling, 2017-05-22, v3.9.0-rc1~57^2) where handling of EXACT
keyword in find_dependency was reworked.

diff --git a/Modules/CMakeFindDependencyMacro.cmake 
b/Modules/CMakeFindDependencyMacro.cmake
index de1a332..ab22701 100644
--- a/Modules/CMakeFindDependencyMacro.cmake
+++ b/Modules/CMakeFindDependencyMacro.cmake
@@ -61,6 +61,5 @@ macro(find_dependency dep)
 endif()
 set(cmake_fd_required_arg)
 set(cmake_fd_quiet_arg)
-set(cmake_fd_exact_arg)
   endif()
 endmacro()

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b127e0c5610221d10c1d6658db96741ab85a083c
commit b127e0c5610221d10c1d6658db96741ab85a083c
Author: Brad King 
AuthorDate: Tue Mar 26 10:40:11 2019 -0400
Commit: Brad King 
CommitDate: Tue Mar 26 10:43:51 2019 -0400

CUDA: Tolerate square brackets in PROMPT environment variable

The `PROMPT` environment variable affects nvcc's output.  Fix
our parsing of that output to tolerate square brackets.

Fixes: #19089

diff --git a/Modules/CMakeDetermineCUDACompiler.cmake 
b/Modules/CMakeDetermineCUDACompiler.cmake
index 113b520..490d659 100644
--- a/Modules/CMakeDetermineCUDACompiler.cmake
+++ b/Modules/CMakeDetermineCUDACompiler.cmake
@@ -111,10 +111,15 @@ elseif(CMAKE_CUDA_COMPILER_ID STREQUAL NVIDIA)
   if(_nvcc_libraries)
 # Remove variable assignments.
 string(REGEX REPLACE "#\\\$ *[^= ]+=[^\n]*\n" "" _nvcc_output 
"${_nvcc_output_orig}")
+# Encode [] characters that break list expansion.
+string(REPLACE "[" "{==={" _nvcc_output "${_nvcc_output}")
+string(REPLACE "]" "}===}" _nvcc_output "${_nvcc_output}")
 # Split lines.
 string(REGEX REPLACE "\n+(#\\\$ )?" ";" _nvcc_output "${_nvcc_output}")
 foreach(line IN LISTS _nvcc_output)
   set(_nvcc_output_line "${line}")
+  string(REPLACE "{==={" "[" _nvcc_output_line "${_nvcc_output_line}")
+  string(REPLACE "}===}" "]" _nvcc_output_line "${_nvcc_output_line}")
   string(APPEND _nvcc_log "  considering line: [${_nvcc_output_line}]\n")
   if("${_nvcc_output_line}" MATCHES "^ *nvlink")
 string(APPEND _nvcc_log "ignoring nvlink line\n")

---

Summary of changes:
 Modules/CMakeDetermineCUDACompiler.cmake | 5 +
 Modules/CMakeFindDependencyMacro.cmake   | 1 -
 2 files changed, 5 insertions(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

Re: [CMake] Parent component options passed to ExternalProject

[Dustyn Blasig]

Thanks for the help, I will give the FetchContent approach a shot and see
how things go. I was actually in the process of trying to do a custom
command using the built-in "cmake -E tar xvf" approach to roll a custom
FetchContent that doesn't need such a new CMake, but I can't get it to work
with zip files even though it seems like it should at this point. I'm
hoping the fetch and include as subdirectory will be a more stable approach.

On Tue, Mar 26, 2019 at 4:39 PM Craig Scott  wrote:

>
>
> On Tue, Mar 26, 2019 at 4:02 AM Dustyn Blasig  wrote:
>
>> Hi All,
>>
>> I'm really struggling to use ExternalProject_Add() in our CMake project.
>>
>> Based on the documentation, I was expecting the simplest Git-based
>> external project with all defaults to act just like using a Git submodule
>> locked at a specific commit.
>>
>> include(ExternalProject)ExternalProject_Add(foobar  GIT_REPOSITORY
>> g...@github.com:FooCo/FooBar.git  GIT_TAG   origin/release/1.2.3)
>>
>> The documentation states "The default configure command runs CMake with
>> options based on the main project.", so I was expecting any options we pass
>> to the owning project such as CMAKE_INSTALL_PREFIX and other variables
>> would get propagated to the ExternalProject. However, that doesn't seem to
>> be the case. Do I need to explicitly apply every variable through the
>> "CMAKE_ARGS" options? If so,
>>
>
> Some basic details are passed down to the external project, but I don't
> recall exactly which variables. I don't think there are a lot of them and I
> do tend to find that I need to pass down some vars in my own projects. You
> may have to dig into the ExternalProject module's source to get
> confirmation for yourself, possibly also look into what the
> external_process() command's implementation does as well.
>
>
>
>> Also, unless I specify a custom CONFIGURE_COMMAND, I can't figure out how
>> to make the configure step happen during the parent projects configure
>> step. Should that be happening? If not, is there a simple way to force it
>> to happen without having to duplicate everything the default options do?
>> I'm seeing mixed results with online resources, along with many older
>> examples that just don't work anymore.
>>
>
> The external project's configure step happens during the main project's
> build stage, just like every other step of ExternalProject_Add(). This will
> be the case whether you override the CONFIGURE_COMMAND or not. If you
> really need the configure step to occur during the main project's configure
> stage, then you have at least a couple of options:
>
>- Consider using the FetchContent module instead and bring the
>external project into your main build directly. If this suits your
>scenario, then I'd recommend this method. I use this a lot and it seems to
>be growing in popularity. It requires CMake 3.11 or later.
>- Go for a pure superbuild approach where your main project does
>nothing more than call various ExternalProject functions to tie together
>different external projects (i.e. your main project doesn't add any
>targets, etc. of its own). This will mean that even though the configure
>steps all occur during the main project's build step, you can control the
>dependencies between the different external projects' steps so that they
>can find what they need from each other (I'm guessing here that you want
>the external project's configure stage to run during your main project's
>build stage so that something later in your main project's configure stage
>can make use of something the external project's configure stage does). You
>will still have to explicitly specify a number of variables to be passed
>through to each external project's configure stage though, so maybe this
>doesn't solve the problem you are facing.
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> Get the hand-book for every CMake user: Professional CMake: A Practical
> Guide 
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, master, updated. v3.14.0-537-gfcfbc01

[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  fcfbc01d68aac2eca7435bfa0f01e5d1b3524303 (commit)
   via  de0d57c97abe88a1025d5a26ed94a82438468349 (commit)
   via  ecc782c75d7ce98c03164f616e9adf9760ce0d7f (commit)
   via  be2764a6576baf4b380cfcf5418284e9bee80dfa (commit)
   via  2bfee8a58b01fc94db56dc0ed8bb5da3f33cf2a6 (commit)
   via  a65a404186c69fabc61ea87459e22110c998fb1b (commit)
   via  ff91071a14885b9e031b262e5d576b8f174870a2 (commit)
   via  afc4612fa57da09748745fefac02a2086f374db1 (commit)
   via  72b0eeeb21807132e110011add7a243a01653f83 (commit)
   via  db182eb160f2e61bebeb1bb5f289a6d899da18da (commit)
   via  30495bb1c291627f94912049da6e06d951a062ec (commit)
   via  0dcef68cd8961f8b3d89edbf46093949778daac8 (commit)
   via  5db17e9d8107629c1dabd0c1e2bf26429e5d841d (commit)
   via  ccf76c6e4cfd9fc7b04db099f7e165cda2336096 (commit)
   via  7742bf4ff5180f85bc4401745e11ce6e031f32e7 (commit)
   via  2c14eb4852924e5423d58785e2cb3bcd72af7710 (commit)
   via  f6241db3e0b69fbf99835b955b17be0f253a742f (commit)
   via  3c09bf0fa7139be0215224ef85a4c2d3c38227f0 (commit)
   via  856a271fb7023e5ee1a251a9ebe55c91072d9cf6 (commit)
   via  46075091d55334d04a2f11207cfedee10149b1d3 (commit)
   via  2cd41046007de479f660a7794292105908276345 (commit)
   via  fa8e2dfc7b10066b2ba575c20ea96d802109e6c3 (commit)
   via  c9bd2e941f106c4c23bb2bb2623991251b528aa5 (commit)
  from  c518f305bb8344e79cb2487f8bc0186a0b0c0336 (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=fcfbc01d68aac2eca7435bfa0f01e5d1b3524303
commit fcfbc01d68aac2eca7435bfa0f01e5d1b3524303
Merge: c518f30 de0d57c
Author: Brad King 
AuthorDate: Wed Mar 27 17:25:21 2019 +
Commit: Kitware Robot 
CommitDate: Wed Mar 27 13:25:35 2019 -0400

Merge topic 'cmTarget_pimpl'

de0d57c97a cmTarget: Use std::unique_ptr instead of custom smart pointer
ecc782c75d cmTarget: Single line comment clanups
be2764a657 cmTarget: Make private `SetPropertyDefault` an in code lambda 
`InitProperty`
2bfee8a58b cmTarget: Remove obsolete `friend` definitions
a65a404186 cmTarget: Inline private HasImportLibrary method
ff91071a14 cmTarget: Move member method `CheckImportedLibName` to impl
afc4612fa5 cmTarget: Move member method `ProcessSourceItemCMP0049()` to impl
72b0eeeb21 cmTarget: Move member booleans to impl
...

Acked-by: Kitware Robot 
Acked-by: Daniel Pfeifer 
Merge-request: !3142


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=de0d57c97abe88a1025d5a26ed94a82438468349
commit de0d57c97abe88a1025d5a26ed94a82438468349
Author: Sebastian Holtermann 
AuthorDate: Sat Mar 23 19:38:30 2019 +0100
Commit: Sebastian Holtermann 
CommitDate: Sat Mar 23 22:22:34 2019 +0100

cmTarget: Use std::unique_ptr instead of custom smart pointer

To manage the lifetime of `cmTargetInternals`, the private implementation of
`cmTarget`, use `std::unique_ptr` instead of
`cmTargetInternalPointer`, which is removed.

`cmTarget` is made non-copyable but movable.

diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index a92bb9b..38bff1b 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -215,6 +215,7 @@ public:
 
 cmTarget::cmTarget(std::string const& name, cmStateEnums::TargetType type,
Visibility vis, cmMakefile* mf)
+  : impl(cm::make_unique())
 {
   assert(mf);
   impl->TargetType = type;
@@ -500,6 +501,11 @@ cmTarget::cmTarget(std::string const& name, 
cmStateEnums::TargetType type,
   }
 }
 
+cmTarget::cmTarget(cmTarget&&) noexcept = default;
+cmTarget::~cmTarget() = default;
+
+cmTarget& cmTarget::operator=(cmTarget&&) noexcept = default;
+
 cmStateEnums::TargetType cmTarget::GetType() const
 {
   return impl->TargetType;
@@ -1967,37 +1973,3 @@ bool cmTarget::GetMappedConfig(std::string const& 
desired_config,
 
   return true;
 }
-
-cmTargetInternalPointer::cmTargetInternalPointer()
-{
-  this->Pointer = new cmTargetInternals;
-}
-
-cmTargetInternalPointer::cmTargetInternalPointer(
-  cmTargetInternalPointer const& r)
-{
-  // Ideally cmTarget instances should never be copied.  However until
-  // we can make a sweep to remove that, this copy constructor avoids
-  // allowing the resources (Internals) to be copied.
-  this->Pointer = new cmTargetInternals(*r.Pointer);
-}
-
-cmTargetInternalPointer::~cmTargetInternalPointer()
-{
-  delete this->Pointer;
-}
-
-cmTargetInternalPointer& cmTargetInternalPointer::operator=(
-  cmTargetInternalPointer const& r)
-{
-  if (this == ) 

[Cmake-commits] CMake branch, master, updated. v3.14.0-514-gc518f30

[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  c518f305bb8344e79cb2487f8bc0186a0b0c0336 (commit)
   via  5e958ccd79024cb0dbd654ecd71120e6367d6cc4 (commit)
   via  07f3082d3b52f1bcba8dd4ef82b3e02c362b392e (commit)
  from  d2c0350c7b2e4e30673ddd09a7c6b1413b0c9471 (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=c518f305bb8344e79cb2487f8bc0186a0b0c0336
commit c518f305bb8344e79cb2487f8bc0186a0b0c0336
Merge: d2c0350 5e958cc
Author: Kyle Edwards 
AuthorDate: Wed Mar 27 16:07:46 2019 +
Commit: Kitware Robot 
CommitDate: Wed Mar 27 12:07:58 2019 -0400

Merge topic 'update-policy-documentation'

5e958ccd79 Help: Improve Cache documentation
07f3082d3b Help: Improve documentation links and formatting

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5e958ccd79024cb0dbd654ecd71120e6367d6cc4
commit 5e958ccd79024cb0dbd654ecd71120e6367d6cc4
Author: Bartosz Kosiorek 
AuthorDate: Wed Mar 27 09:57:30 2019 +0100
Commit: Bartosz Kosiorek 
CommitDate: Wed Mar 27 16:01:29 2019 +0100

Help: Improve Cache documentation

diff --git a/Help/prop_cache/ADVANCED.rst b/Help/prop_cache/ADVANCED.rst
index a0a4f73..ec4de9d 100644
--- a/Help/prop_cache/ADVANCED.rst
+++ b/Help/prop_cache/ADVANCED.rst
@@ -4,5 +4,5 @@ ADVANCED
 True if entry should be hidden by default in GUIs.
 
 This is a boolean value indicating whether the entry is considered
-interesting only for advanced configuration.  The mark_as_advanced()
+interesting only for advanced configuration.  The :command:`mark_as_advanced`
 command modifies this property.
diff --git a/Help/prop_cache/STRINGS.rst b/Help/prop_cache/STRINGS.rst
index 2f8e32e..0e3c326 100644
--- a/Help/prop_cache/STRINGS.rst
+++ b/Help/prop_cache/STRINGS.rst
@@ -1,9 +1,9 @@
 STRINGS
 ---
 
-Enumerate possible STRING entry values for GUI selection.
+Enumerate possible ``STRING`` entry values for GUI selection.
 
-For cache entries with type STRING, this enumerates a set of values.
+For cache entries with type ``STRING``, this enumerates a set of values.
 CMake GUIs may use this to provide a selection widget instead of a
 generic string entry field.  This is for convenience only.  CMake does
 not enforce that the value matches one of those listed.
diff --git a/Help/prop_cache/TYPE.rst b/Help/prop_cache/TYPE.rst
index eb75c2a..7ca859f 100644
--- a/Help/prop_cache/TYPE.rst
+++ b/Help/prop_cache/TYPE.rst
@@ -5,7 +5,7 @@ Widget type for entry in GUIs.
 
 Cache entry values are always strings, but CMake GUIs present widgets
 to help users set values.  The GUIs use this property as a hint to
-determine the widget type.  Valid TYPE values are:
+determine the widget type.  Valid ``TYPE`` values are:
 
 ::
 
@@ -17,5 +17,5 @@ determine the widget type.  Valid TYPE values are:
   STATIC= Value managed by CMake, do not change.
   UNINITIALIZED = Type not yet specified.
 
-Generally the TYPE of a cache entry should be set by the command which
-creates it (set, option, find_library, etc.).
+Generally the ``TYPE`` of a cache entry should be set by the command which
+creates it ( :command:`set`, :command:`option`, :command:`find_library`, etc.).

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=07f3082d3b52f1bcba8dd4ef82b3e02c362b392e
commit 07f3082d3b52f1bcba8dd4ef82b3e02c362b392e
Author: Bartosz Kosiorek 
AuthorDate: Tue Mar 26 16:13:41 2019 +0100
Commit: Bartosz Kosiorek 
CommitDate: Wed Mar 27 16:01:20 2019 +0100

Help: Improve documentation links and formatting

diff --git a/Help/command/aux_source_directory.rst 
b/Help/command/aux_source_directory.rst
index e0af665..9619f35 100644
--- a/Help/command/aux_source_directory.rst
+++ b/Help/command/aux_source_directory.rst
@@ -11,14 +11,14 @@ Collects the names of all the source files in the specified 
directory
 and stores the list in the  provided.  This command is
 intended to be used by projects that use explicit template
 instantiation.  Template instantiation files can be stored in a
-"Templates" subdirectory and collected automatically using this
+``Templates`` subdirectory and collected automatically using this
 command to avoid manually listing all instantiations.
 
 It is tempting to use this command to avoid writing the list of source
 files for a library or executable target.  While this seems to work,
 there is no way for CMake to generate a build system that knows when a
 new source file has been added.  Normally the generated build system
-knows when it needs to rerun CMake because the CMakeLists.txt file is
+knows 

[cmake-developers] Enhance CMake Comportment in AIX

[GUESNET, ETIENNE (ext)]

Hello,
I am working on the AIX port of the CMake. Something exists, but a large part 
is done using some flags, typically -expall and -G. These flag force AIX build 
chain to be more similar than Linux (e.g. use .so while AIX use .a). 
Unfortunately, this solution has side effect and means no any software 
compiling on AIX using CMake will work on the standard AIX way.
I am trying to educate CMake to work better on AIX (in a first time I focus on 
GCC). I change the 'CMAKE_SHARED_LIBRARY_SUFFIX' to ".a" and I adapt the 
'CMAKE_${lang}_CREATE_SHARED_LIBRARY' to create first .so and then use 'ar' to 
create .a. It works.
However, a problem appears during linking: CMake transform -l and -L flag to 
direct link. So, it searches e.g. '../libMyLib.a' and I want '-L.. -lMyLib'. 
This puts a relative path to the executable (I see it with the 'dump' command), 
that is not the expected comportment. Do you know how to change this 
comportment ?
Finally, I have huge troubles with 'dlopen'. In AIX, all symbols are not 
exported by default, export all makes side effect, and we need to export and 
import symbols to correctly use a shared library imported this way. I do not 
find a way to make import/export automatically. As I know, libtools or 
configure mix a two passes compilation and some flag manually added.
Thanks,
Etienne Guesnet.

-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [CMake] Alternative to `add_compile_options` in Toolchain Files

[Cristian Adam]

Hi,

If your CMake version is newer than 3.11 you can control what gets into the
CMAKE__FLAGS_INIT flags with the technique from
https://cristianadam.eu/20190223/modifying-the-default-cmake-build-types/

In your case you want to remove from the linker flags init the cxx compiler
options.

Cheers
Cristian.

On Wed, Mar 27, 2019, 03:10 Jayesh Badwaik  wrote:

> Hi,
>
> In https://gitlab.kitware.com/cmake/cmake/issues/19074, it was mentioned
> that
> instead of `add_compile_options`, `CMAKE_CXX_FLAGS_INIT` should be used.
> An
> issue with this is that `CMAKE_CXX_FLAGS_INIT` flags are propogated to the
> linker as well, wherein, the linker warns about `[-Wunused-command-line-
> argument]` if those warnings are enabled.
>
> Is there an alternative to `CMAKE_CXX_FLAGS_INIT` which avoids these
> issues?
>
> Thanks
>
> --
> Best
> Jayesh Badwaik
> https://jayeshbadwaik.github.io
>
> --
>
> 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:
> https://cmake.org/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:
https://cmake.org/mailman/listinfo/cmake