[CMake] [VS] Error Code Return from add_custom_command() Suppresses Console Output

[Marek Vojtko]

Hi,

I have a custom command that calls an in-house compiler that generates a source 
file set up like this:

add_custom_command(OUTPUT "generatedFile.h" COMMAND "myCompiler.exe -someParam" 
[..])

The compiler prints information to STDOUT like lines where errors or warnings 
occurred.

When the command succeeds (i.e. the compilation succeeds and myCompiler.exe 
returns 0), the compiler's output is correctly printed into the compile output 
(the Build Output window in Visual Studio):

> Generating generatedFile.h
>
>  -someParam
>
> [output from the compiler, including file names and line numbers for warnings]

However, when the command fails (i.e. the compilation fails and myCompiler.exe 
returns a non-zero return code), I don't see the compiler's output. Instead I 
get:

> C:\Program Files (x86)\Microsoft Visual 
> Studio\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(209,5):
>  error MSB6006: "cmd.exe" exited with code -2147483645.

I get this behavior on CMake 3.12 and 3.15. I have tried adding VERBATIM and 
USES_TERMINAL to my add_custom_command() call, but neither helped.

How can I get the custom command's output even when it returns a non-zero 
return code?

Thanks,
Marek
-- 

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] toolchain file - cross-compiling windows-amd64->windows-x86

[Joao Pedro Abreu De Souza]

Cool. I try using this toolchain in a toy project, just to test, and
execute the cmake inside cross-compiling x64_x86 from visual studio 2017
and all work as expected, except the linking from ninja, that break because
cannot find printf.
Is absolutely cool, better than my last toolchain. Do you know how Can I
link with libc from visual studio 2013(that was your example)? From
location on 2013, the 2017 can be deduced, I think.

To make clear, when I said how to link with libc, is literally the path
that I don't know , I know that must use libpath(or set LIB env
variable) with the path, but what path? kkk

Em qua, 18 de set de 2019 às 02:50, Eric Doenges 
escreveu:

> We use ninja for building on Windows. Our toolchain file for the MSVC
> compiler is really simple (this is for MSVC 18.0, 32 bits):
>
> --- SNIP ---
>
> set(CMAKE_SYSTEM_NAME Windows)
> set(CMAKE_SYSTEM_PROCESSOR "x86")
> set(CMAKE_SYSTEM_VERSION 1)
>
> # Microsoft MSVC compiler
> set(CMAKE_C_COMPILER cl.exe)
> set(CMAKE_CXX_COMPILER cl.exe)
>
> # Unfortunatly CMake doesn't seem to know anything about the MSVC compiler,
> # so tell CMake that cl.exe supports C99
> set(CMAKE_C_COMPILE_FEATURES c_std_99)
>
> # If Visual Studio is selected as generator, only allow VS 2013
> if(CMAKE_GENERATOR MATCHES "Visual Studio")
>   if(NOT CMAKE_GENERATOR MATCHES "Visual Studio 12 2013")
> message(FATAL_ERROR "Visual Studio generator requires Visual Studio 12
> 2013"
>   " for this configuration")
>   else()
> # Enable parallel builds for Visual Studio Projects with the /MP flag
> set(_MP_FLAG "/MP")
>   endif()
> endif()
>
> set(CMAKE_C_FLAGS_INIT   "/arch:SSE2 ${_MP_FLAG} /EHsc")
> set(CMAKE_CXX_FLAGS_INIT "/arch:SSE2 ${_MP_FLAG}")
>
> --- SNIP ---
>
> However, there is a major snag (naturally, since we're talking about
> Windows here) - in order for the Microsoft compiler to work from the
> command line, you need to set the correct environment, and CMake doesn't
> really give you a good way to do this. You can set environment variables
> from CMake, but as the documentation says "This command affects only the
> current CMake process, not the process from which CMake was called, nor the
> system environment at large, nor the environment of subsequent build or
> test processes.".
>
> The solution we use is instead of calling cmake directly, we call a Perl
> script that sets up the environment correctly and then calls cmake for
> configuration or building. An alternative solution would be to write a
> batch script wrapper for cl.exe, something like.
>
> @ECHO OFF
> "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86
> cl.exe %*
>
> and then set this batch script as the C and C++ compiler in CMake (note
> that this is untested - I think it should work, but it may need some extra
> work).
>
> With kind regards,
> Eric
> Am 17.09.19 um 21:46 schrieb fdk17:
>
> As I recall for myself, simply using the Visual Studio Generator with the
> -A option was all that was needed to build for Win32.
> You don't need a toolchain file because the generator already knows how to
> setup a Visual Studio Project to target Win32.
> Even the documentation for cross-compiling doesn't show a need to setup
> toolchain file for cross compiling in this case.
>
> I personally never seen anyone try to use the Ninja generator via command
> line CMake and use the cl.exe compiler.
> I've only seen that using Visual Studio to open a CMakeLists.txt file it
> can produce a Ninja project.  But even MS documentation states that it
> doesn't always work.
>
>
> https://stackoverflow.com/questions/31262342/cmake-g-ninja-on-windows-specify-x64
> This says you should be able to open the proper development window and use
> Ninja.
>
> The output shows that in the environment you are using it doesn't even
> know how to use cl.exe to even determine with compiler it is.  Maybe not
> all the proper environment variables and paths are being set correctly when
> using the compiler.
>
> --
> F
>
> --
>
> *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. Wolfgang Eckstein, Dr. Olaf Munkelt
> Amtsgericht München HRB 114695
>
>
> [image: MVTec Software GmbH Logo]
> --
>
> 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
> 

[Cmake-commits] CMake branch, master, updated. v3.15.3-1075-g1423507

[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  1423507a71199fd76b457ad9b215a6caca70ee58 (commit)
   via  9c45b95ddde04d8429f08fd692d53f843a02d12b (commit)
   via  7f3ecbe7d7210667770d3212e2bfdb0c701cdc5d (commit)
  from  01cce69870ec7efbb8138f5345aa7ffed8b7ac12 (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=1423507a71199fd76b457ad9b215a6caca70ee58
commit 1423507a71199fd76b457ad9b215a6caca70ee58
Merge: 01cce69 9c45b95
Author: Brad King 
AuthorDate: Wed Sep 18 15:51:54 2019 +
Commit: Kitware Robot 
CommitDate: Wed Sep 18 11:52:14 2019 -0400

Merge topic 'command-line-make-functions'

9c45b95ddd cmMakefile: Remove unused AddUtilityCommand overload
7f3ecbe7d7 cmCustomCommandLine: Provide command line make functions

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9c45b95ddde04d8429f08fd692d53f843a02d12b
commit 9c45b95ddde04d8429f08fd692d53f843a02d12b
Author: Daniel Eiband 
AuthorDate: Fri Sep 13 19:45:09 2019 +0200
Commit: Daniel Eiband 
CommitDate: Mon Sep 16 20:45:56 2019 +0200

cmMakefile: Remove unused AddUtilityCommand overload

diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 88d03f9..2c7e5e9 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -1173,35 +1173,6 @@ bool cmMakefile::AppendCustomCommandToOutput(
 
 cmTarget* cmMakefile::AddUtilityCommand(
   const std::string& utilityName, TargetOrigin origin, bool excludeFromAll,
-  const std::vector& depends, const char* workingDirectory,
-  const char* command, const char* arg1, const char* arg2, const char* arg3,
-  const char* arg4)
-{
-  // Construct the command line for the custom command.
-  cmCustomCommandLine commandLine;
-  commandLine.push_back(command);
-  if (arg1) {
-commandLine.push_back(arg1);
-  }
-  if (arg2) {
-commandLine.push_back(arg2);
-  }
-  if (arg3) {
-commandLine.push_back(arg3);
-  }
-  if (arg4) {
-commandLine.push_back(arg4);
-  }
-  cmCustomCommandLines commandLines;
-  commandLines.push_back(std::move(commandLine));
-
-  // Call the real signature of this method.
-  return this->AddUtilityCommand(utilityName, origin, excludeFromAll,
- workingDirectory, depends, commandLines);
-}
-
-cmTarget* cmMakefile::AddUtilityCommand(
-  const std::string& utilityName, TargetOrigin origin, bool excludeFromAll,
   const char* workingDirectory, const std::vector& depends,
   const cmCustomCommandLines& commandLines, bool escapeOldStyle,
   const char* comment, bool uses_terminal, bool command_expand_lists,
diff --git a/Source/cmMakefile.h b/Source/cmMakefile.h
index 1944879..6d695a7 100644
--- a/Source/cmMakefile.h
+++ b/Source/cmMakefile.h
@@ -243,14 +243,6 @@ public:
* Add a utility to the build.  A utility target is a command that
* is run every time the target is built.
*/
-  cmTarget* AddUtilityCommand(const std::string& utilityName,
-  TargetOrigin origin, bool excludeFromAll,
-  const std::vector& depends,
-  const char* workingDirectory,
-  const char* command, const char* arg1 = nullptr,
-  const char* arg2 = nullptr,
-  const char* arg3 = nullptr,
-  const char* arg4 = nullptr);
   cmTarget* AddUtilityCommand(
 const std::string& utilityName, TargetOrigin origin, bool excludeFromAll,
 const char* workingDirectory, const std::vector& depends,

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7f3ecbe7d7210667770d3212e2bfdb0c701cdc5d
commit 7f3ecbe7d7210667770d3212e2bfdb0c701cdc5d
Author: Daniel Eiband 
AuthorDate: Fri Sep 13 19:44:37 2019 +0200
Commit: Daniel Eiband 
CommitDate: Mon Sep 16 20:45:41 2019 +0200

cmCustomCommandLine: Provide command line make functions

Reduce boilerplate necessary to create custom command lines by introducing 
and
applying cmMakeCommandLine and cmMakeSingleCommandLine functions.

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index decb39a..65cd6c9 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -191,6 +191,8 @@ set(SRCS
   cmCustomCommand.h
   cmCustomCommandGenerator.cxx
   cmCustomCommandGenerator.h
+  cmCustomCommandLines.cxx
+  cmCustomCommandLines.h
   cmDefinitions.cxx
   cmDefinitions.h
   cmDepends.cxx
diff --git a/Source/cmCustomCommandLines.cxx b/Source/cmCustomCommandLines.cxx
new file mode 100644
index 000..37ad75b
--- 

[Cmake-commits] CMake branch, master, updated. v3.15.3-1072-g01cce69

[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  01cce69870ec7efbb8138f5345aa7ffed8b7ac12 (commit)
   via  a981a9a7451bbabdc5048f982dce4b3553fe9711 (commit)
   via  c9c1eb99fe011546b5d9390c7fbbeebfda491c65 (commit)
   via  729d997f1073c7a177da5b46b073a08b95adfa74 (commit)
  from  45b7d5284e11cb34885b756bee8dedeb94fc16cb (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=01cce69870ec7efbb8138f5345aa7ffed8b7ac12
commit 01cce69870ec7efbb8138f5345aa7ffed8b7ac12
Merge: a981a9a c9c1eb9
Author: Kyle Edwards 
AuthorDate: Wed Sep 18 15:35:13 2019 +
Commit: Kitware Robot 
CommitDate: Wed Sep 18 11:36:03 2019 -0400

Merge topic 'smart_ptr/cmCPackGeneratorFactory'

c9c1eb99fe cmCPackGeneratorFactory: rule of zero

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a981a9a7451bbabdc5048f982dce4b3553fe9711
commit a981a9a7451bbabdc5048f982dce4b3553fe9711
Merge: 45b7d52 729d997
Author: Brad King 
AuthorDate: Wed Sep 18 15:33:23 2019 +
Commit: Kitware Robot 
CommitDate: Wed Sep 18 11:34:00 2019 -0400

Merge topic 'shared-pch'

729d997f10 Precompile Headers: Add REUSE_FROM signature

Acked-by: Kitware Robot 
Acked-by: Rickard Englund 
Acked-by: Viktor Kirilov 
Merge-request: !3762


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c9c1eb99fe011546b5d9390c7fbbeebfda491c65
commit c9c1eb99fe011546b5d9390c7fbbeebfda491c65
Author: Tushar Maheshwari 
AuthorDate: Sat Sep 7 14:15:08 2019 +0530
Commit: Kyle Edwards 
CommitDate: Tue Sep 17 13:05:26 2019 -0400

cmCPackGeneratorFactory: rule of zero

diff --git a/Source/CPack/cmCPackGeneratorFactory.cxx 
b/Source/CPack/cmCPackGeneratorFactory.cxx
index a564eb1..79e344b 100644
--- a/Source/CPack/cmCPackGeneratorFactory.cxx
+++ b/Source/CPack/cmCPackGeneratorFactory.cxx
@@ -6,7 +6,6 @@
 #include 
 
 #include "IFW/cmCPackIFWGenerator.h"
-#include "cmAlgorithms.h"
 #ifdef HAVE_FREEBSD_PKG
 #  include "cmCPackFreeBSDGenerator.h"
 #endif
@@ -138,33 +137,21 @@ cmCPackGeneratorFactory::cmCPackGeneratorFactory()
 #endif
 }
 
-cmCPackGeneratorFactory::~cmCPackGeneratorFactory()
-{
-  cmDeleteAll(this->Generators);
-}
-
-cmCPackGenerator* cmCPackGeneratorFactory::NewGenerator(
+std::unique_ptr cmCPackGeneratorFactory::NewGenerator(
   const std::string& name)
 {
-  cmCPackGenerator* gen = this->NewGeneratorInternal(name);
+  auto it = this->GeneratorCreators.find(name);
+  if (it == this->GeneratorCreators.end()) {
+return nullptr;
+  }
+  std::unique_ptr gen(it->second());
   if (!gen) {
 return nullptr;
   }
-  this->Generators.push_back(gen);
   gen->SetLogger(this->Logger);
   return gen;
 }
 
-cmCPackGenerator* cmCPackGeneratorFactory::NewGeneratorInternal(
-  const std::string& name)
-{
-  auto it = this->GeneratorCreators.find(name);
-  if (it == this->GeneratorCreators.end()) {
-return nullptr;
-  }
-  return (it->second)();
-}
-
 void cmCPackGeneratorFactory::RegisterGenerator(
   const std::string& name, const char* generatorDescription,
   CreateGeneratorCall* createGenerator)
diff --git a/Source/CPack/cmCPackGeneratorFactory.h 
b/Source/CPack/cmCPackGeneratorFactory.h
index da2eb8d..62b7484 100644
--- a/Source/CPack/cmCPackGeneratorFactory.h
+++ b/Source/CPack/cmCPackGeneratorFactory.h
@@ -6,8 +6,8 @@
 #include "cmConfigure.h" // IWYU pragma: keep
 
 #include 
+#include 
 #include 
-#include 
 
 class cmCPackGenerator;
 class cmCPackLog;
@@ -20,14 +20,9 @@ class cmCPackGeneratorFactory
 {
 public:
   cmCPackGeneratorFactory();
-  ~cmCPackGeneratorFactory();
-
-  cmCPackGeneratorFactory(const cmCPackGeneratorFactory&) = delete;
-  cmCPackGeneratorFactory& operator=(const cmCPackGeneratorFactory&) = delete;
 
   //! Get the generator
-  cmCPackGenerator* NewGenerator(const std::string& name);
-  void DeleteGenerator(cmCPackGenerator* gen);
+  std::unique_ptr NewGenerator(const std::string& name);
 
   using CreateGeneratorCall = cmCPackGenerator*();
 
@@ -44,9 +39,6 @@ public:
   }
 
 private:
-  cmCPackGenerator* NewGeneratorInternal(const std::string& name);
-  std::vector Generators;
-
   using t_GeneratorCreatorsMap = std::map;
   t_GeneratorCreatorsMap GeneratorCreators;
   DescriptionsMap GeneratorDescriptions;
diff --git a/Source/CPack/cpack.cxx b/Source/CPack/cpack.cxx
index ab44a42..ce41d40 100644
--- a/Source/CPack/cpack.cxx
+++ b/Source/CPack/cpack.cxx
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -237,7 +238,6 @@ int main(int argc, char const* const* argv)
 

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

[Simon Richter]

Hi,

On Tue, Sep 17, 2019 at 04:21:36PM -0700, Alan W. Irwin wrote:

> * 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?

The PUBLIC option is required if your library has inline functions that
directly call a dependent library.

On Windows, "shared" linking uses import stubs. Symbols used by dependent
libs were resolved when the dependent lib was linked, so they are not
available anymore. On ELF systems, whether symbols from indirectly linked
libs are available is implementation dependent -- older versions of glibc's
ld.so built a global namespace, so it might appear to work there, but that
is not guaranteed.

My expectation is that PRIVATE should work in all cases as long as your use
of the dependent library is indeed private -- i.e. doesn't affect the
binary interface of your library. Ideally, your headers wouldn't include
their headers, but in reality requirements are a bit more relaxed, so you
are fine as long as you don't have inline functions in headers that call
into the private dependency, and any compiler flags that affect data layout
in any shared types are consistent (e.g. if you use GLM, then
the definition of GLM_FORCE_PURE must be PUBLIC, because that affects
struct alignment requirements).

A good way to test is to do a fully static build with a compiler that
supports link time optimization and provides diagnostics for mismatches.
For example, we know we have a bug in the way KiCad uses GLM, because we
get -Wlto warnings[1] about that.

   Simon

[1] https://jenkins.simonrichter.eu/job/linux-kicad-head-lto/24/gcc/
-- 

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] toolchain file - cross-compiling windows-amd64->windows-x86

[Eric Doenges]

We use ninja for building on Windows. Our toolchain file for the MSVC 
compiler is really simple (this is for MSVC 18.0, 32 bits):


--- SNIP ---

set(CMAKE_SYSTEM_NAME Windows)
set(CMAKE_SYSTEM_PROCESSOR "x86")
set(CMAKE_SYSTEM_VERSION 1)

# Microsoft MSVC compiler
set(CMAKE_C_COMPILER cl.exe)
set(CMAKE_CXX_COMPILER cl.exe)

# Unfortunatly CMake doesn't seem to know anything about the MSVC compiler,
# so tell CMake that cl.exe supports C99
set(CMAKE_C_COMPILE_FEATURES c_std_99)

# If Visual Studio is selected as generator, only allow VS 2013
if(CMAKE_GENERATOR MATCHES "Visual Studio")
  if(NOT CMAKE_GENERATOR MATCHES "Visual Studio 12 2013")
    message(FATAL_ERROR "Visual Studio generator requires Visual Studio 
12 2013"

  " for this configuration")
  else()
    # Enable parallel builds for Visual Studio Projects with the /MP flag
    set(_MP_FLAG "/MP")
  endif()
endif()

set(CMAKE_C_FLAGS_INIT   "/arch:SSE2 ${_MP_FLAG} /EHsc")
set(CMAKE_CXX_FLAGS_INIT "/arch:SSE2 ${_MP_FLAG}")

--- SNIP ---

However, there is a major snag (naturally, since we're talking about 
Windows here) - in order for the Microsoft compiler to work from the 
command line, you need to set the correct environment, and CMake doesn't 
really give you a good way to do this. You can set environment variables 
from CMake, but as the documentation says "This command affects only the 
current CMake process, not the process from which CMake was called, nor 
the system environment at large, nor the environment of subsequent build 
or test processes.".


The solution we use is instead of calling cmake directly, we call a Perl 
script that sets up the environment correctly and then calls cmake for 
configuration or building. An alternative solution would be to write a 
batch script wrapper for cl.exe, something like.


@ECHO OFF
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86
cl.exe %*

and then set this batch script as the C and C++ compiler in CMake (note 
that this is untested - I think it should work, but it may need some 
extra work).


With kind regards,
Eric

Am 17.09.19 um 21:46 schrieb fdk17:
As I recall for myself, simply using the Visual Studio Generator with 
the -A option was all that was needed to build for Win32.
You don't need a toolchain file because the generator already knows 
how to setup a Visual Studio Project to target Win32.
Even the documentation for cross-compiling doesn't show a need to 
setup toolchain file for cross compiling in this case.


I personally never seen anyone try to use the Ninja generator via 
command line CMake and use the cl.exe compiler.
I've only seen that using Visual Studio to open a CMakeLists.txt file 
it can produce a Ninja project.  But even MS documentation states that 
it doesn't always work.


https://stackoverflow.com/questions/31262342/cmake-g-ninja-on-windows-specify-x64
This says you should be able to open the proper development window and 
use Ninja.


The output shows that in the environment you are using it doesn't even 
know how to use cl.exe to even determine with compiler it is.  Maybe 
not all the proper environment variables and paths are being set 
correctly when using the compiler.


--
F

--

*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. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

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.15.3-1068-g45b7d52

[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  45b7d5284e11cb34885b756bee8dedeb94fc16cb (commit)
  from  e6ddb57479a3620c712719c120a7337a84470d21 (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=45b7d5284e11cb34885b756bee8dedeb94fc16cb
commit 45b7d5284e11cb34885b756bee8dedeb94fc16cb
Author: Kitware Robot 
AuthorDate: Wed Sep 18 00:01:07 2019 -0400
Commit: Kitware Robot 
CommitDate: Wed Sep 18 00:01:07 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 887d970..1e0721f 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 15)
-set(CMake_VERSION_PATCH 20190917)
+set(CMake_VERSION_PATCH 20190918)
 #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

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

[Alan W. Irwin]

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?

* 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?

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.

* For static libraries always uses the PUBLIC TLL option.

These decisions were based on my own understanding of transitive
linking needs for static Unix libraries and shared and static Windows
libraries many years ago, but now it appears that understanding is out
of date or else was wrong in the first place.

For example, in the static Linux case there is a nasty leakage of
compile and link flags between static libraries that I have just
tripped over when dealing with the D ldc2 compiler which cannot
understand those flags which are generated for the gcc compiler for a
C library which our D library depends on.  So to stop that leakage,
and in light of what you said three years ago, it appears to be a
no-brainer to use PRIVATE TLL for the PLplot static libraries at least
in the Unix case.  So assuming that for the PLplot build system I
follow up and prove that PRIVATE TLL works for both the shared and
static library cases on Unix, would you also recommend PLplot move to
PRIVATE TLL for both the shared and static library cases on Windows?

Thanks in advance for your further comments on these matters.

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 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] toolchain file - cross-compiling windows-amd64->windows-x86

[Joao Pedro Abreu De Souza]

Well, the Visual Studio Generator alone is not a option because the
repository has a actual build system(a bunch of bat files that call a
python script that generate ninja files).
We want to change to cmake, and now we don't use Visual Studio a lot. Most
of time, we only need their compiler and linker.

Well, Thanks all for the attention, sorry about the time wasted. I will
continue to search to exactly options and, in case of sucess, mail here
again.
Great day to all of you.

Em ter, 17 de set de 2019 às 16:56, fdk17  escreveu:

> As I recall for myself, simply using the Visual Studio Generator with the
> -A option was all that was needed to build for Win32.
> You don't need a toolchain file because the generator already knows how to
> setup a Visual Studio Project to target Win32.
> Even the documentation for cross-compiling doesn't show a need to setup
> toolchain file for cross compiling in this case.
>
> I personally never seen anyone try to use the Ninja generator via command
> line CMake and use the cl.exe compiler.
> I've only seen that using Visual Studio to open a CMakeLists.txt file it
> can produce a Ninja project.  But even MS documentation states that it
> doesn't always work.
>
>
> https://stackoverflow.com/questions/31262342/cmake-g-ninja-on-windows-specify-x64
> This says you should be able to open the proper development window and use
> Ninja.
>
> The output shows that in the environment you are using it doesn't even
> know how to use cl.exe to even determine with compiler it is.  Maybe not
> all the proper environment variables and paths are being set correctly when
> using the compiler.
>
> --
> F
>
> On Tue, Sep 17, 2019, at 3:11 PM, Joao Pedro Abreu De Souza wrote:
>
> Thanks, I'll check it out.
>
> The toolchain file, as is, can generate ninja builds that can be used to
> generate a executable, but when I execute them, he say :
>
> ```
> -- The C compiler identification is unknown
> -- The CXX compiler identification is unknown
> -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
> Studio 12.0/VC/bin/amd64_x86/cl.exe
> -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
> Studio 12.0/VC/bin/amd64_x86/cl.exe -- broken
> CMake Error at C:/Program
> Files/CMake/share/cmake-3.15/Modules/CMakeTestCCompiler.cmake:60 (message):
>   The C compiler
>
> "C:/Program Files (x86)/Microsoft Visual Studio
> 12.0/VC/bin/amd64_x86/cl.exe"
>
>   is not able to compile a simple test program.
>
>   It fails with the following output:
>
> Change Dir:
> C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/CMakeTmp
>
> Run Build Command(s):C:/ProgramData/chocolatey/bin/ninja.exe
> cmTC_0dfb4 && [1/2] Building C object
> CMakeFiles\cmTC_0dfb4.dir\testCCompiler.c.obj
> FAILED: CMakeFiles/cmTC_0dfb4.dir/testCCompiler.c.obj
> "C:\PROGRA~2\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\cl.exe"
>  -o CMakeFiles\cmTC_0dfb4.dir\testCCompiler.c.obj   -c testCCompiler.c
> ninja: build stopped: subcommand failed.
>
>
>
>
>
>   CMake will not be able to correctly generate this project.
> Call Stack (most recent call first):
>   CMakeLists.txt:2 (project)
> ```
>
> Em ter, 17 de set de 2019 às 16:02, Juan Sanchez 
> escreveu:
>
> From my brief research, it looks like the Microsoft version of CMake may
> have Ninja support.
>
>
> https://devblogs.microsoft.com/cppblog/cmake-support-in-visual-studio-whats-new-in-2017-15-3-update/
>
>
> Regards,
>
> Juan
>
> On Tue, Sep 17, 2019 at 1:36 PM Joao Pedro Abreu De Souza <
> jp_ab...@id.uff.br> wrote:
>
> So, only the Visual Studio generator use the Arch option? I try generate
> ninja build, but cmake(3.15.3) and the answer was
>
> ```
> $ cmake -B build -S . -G "Ninja" -A Win32
> CMake Error at CMakeLists.txt:2 (project):
>   Generator
>
> Ninja
>
>   does not support platform specification, but platform
>
> Win32
>
>   was specified.
>
>
> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
> CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
> -- Configuring incomplete, errors occurred!
> See also
> "C:/Users/jpabreu/Desktop/testCMAKE/build/CMakeFiles/CMakeOutput.log".
> ```
>
> Em ter, 17 de set de 2019 às 14:00, Juan Sanchez 
> escreveu:
>
> Hello,
>
> My impression that targeting 32 bit depends on what generator you are
> using.
>
> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html
>
> It looks like cmake now has:
>
>- cmake -G "Visual Studio 15 2017" -A Win32
>- cmake -G "Visual Studio 15 2017" -A x64
>
> It used to be that the default target platform was Win32, and  you had to
> specify Win64 in the generator string to target a 64 bit build.  For
> example with Visual Studio 2015
>
>
> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html
>
> For compatibility with CMake versions prior to 3.1, one may specify a
> target platform name optionally at the end of the generator name. This is
> supported 

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[fdk17]

As I recall for myself, simply using the Visual Studio Generator with the -A 
option was all that was needed to build for Win32.
You don't need a toolchain file because the generator already knows how to 
setup a Visual Studio Project to target Win32.
Even the documentation for cross-compiling doesn't show a need to setup 
toolchain file for cross compiling in this case.

I personally never seen anyone try to use the Ninja generator via command line 
CMake and use the cl.exe compiler.
I've only seen that using Visual Studio to open a CMakeLists.txt file it can 
produce a Ninja project. But even MS documentation states that it doesn't 
always work.

https://stackoverflow.com/questions/31262342/cmake-g-ninja-on-windows-specify-x64
This says you should be able to open the proper development window and use 
Ninja.

The output shows that in the environment you are using it doesn't even know how 
to use cl.exe to even determine with compiler it is. Maybe not all the proper 
environment variables and paths are being set correctly when using the compiler.

--
F

On Tue, Sep 17, 2019, at 3:11 PM, Joao Pedro Abreu De Souza wrote:
> Thanks, I'll check it out.
> 
> The toolchain file, as is, can generate ninja builds that can be used to 
> generate a executable, but when I execute them, he say : 
> 
> ```
> -- The C compiler identification is unknown
> -- The CXX compiler identification is unknown
> -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual 
> Studio 12.0/VC/bin/amd64_x86/cl.exe
> -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual 
> Studio 12.0/VC/bin/amd64_x86/cl.exe -- broken
> CMake Error at C:/Program 
> Files/CMake/share/cmake-3.15/Modules/CMakeTestCCompiler.cmake:60 (message):
>  The C compiler
> 
>  "C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64_x86/cl.exe"
> 
>  is not able to compile a simple test program.
> 
>  It fails with the following output:
> 
>  Change Dir: 
> C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/CMakeTmp
> 
>  Run Build Command(s):C:/ProgramData/chocolatey/bin/ninja.exe cmTC_0dfb4 && 
> [1/2] Building C object CMakeFiles\cmTC_0dfb4.dir\testCCompiler.c.obj
>  FAILED: CMakeFiles/cmTC_0dfb4.dir/testCCompiler.c.obj
>  "C:\PROGRA~2\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\cl.exe" -o 
> CMakeFiles\cmTC_0dfb4.dir\testCCompiler.c.obj -c testCCompiler.c
>  ninja: build stopped: subcommand failed.
> 
> 
> 
> 
> 
>  CMake will not be able to correctly generate this project.
> Call Stack (most recent call first):
>  CMakeLists.txt:2 (project)
> ```
> 
> Em ter, 17 de set de 2019 às 16:02, Juan Sanchez  
> escreveu:
>> From my brief research, it looks like the Microsoft version of CMake may 
>> have Ninja support.
>> 
>> https://devblogs.microsoft.com/cppblog/cmake-support-in-visual-studio-whats-new-in-2017-15-3-update/
>>  
>> 
>> Regards,
>> 
>> Juan
>> 
>> On Tue, Sep 17, 2019 at 1:36 PM Joao Pedro Abreu De Souza 
>>  wrote:
>>> So, only the Visual Studio generator use the Arch option? I try generate 
>>> ninja build, but cmake(3.15.3) and the answer was 
>>> 
>>> ```
>>> $ cmake -B build -S . -G "Ninja" -A Win32
>>> CMake Error at CMakeLists.txt:2 (project):
>>>  Generator
>>> 
>>>  Ninja
>>> 
>>>  does not support platform specification, but platform
>>> 
>>>  Win32
>>> 
>>>  was specified.
>>> 
>>> 
>>> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
>>> CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
>>> -- Configuring incomplete, errors occurred!
>>> See also 
>>> "C:/Users/jpabreu/Desktop/testCMAKE/build/CMakeFiles/CMakeOutput.log".
>>> ```
>>> 
>>> Em ter, 17 de set de 2019 às 14:00, Juan Sanchez  
>>> escreveu:
 Hello,
 
 My impression that targeting 32 bit depends on what generator you are 
 using.
 https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html
 
 It looks like cmake now has:
  * `cmake -G "Visual Studio 15 2017" -A Win32`
  * `cmake -G "Visual Studio 15 2017" -A x64`
 It used to be that the default target platform was Win32, and you had to 
 specify Win64 in the generator string to target a 64 bit build. For 
 example with Visual Studio 2015
 
 https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html
 
 For compatibility with CMake versions prior to 3.1, one may specify a 
 target platform name optionally at the end of the generator name. This is 
 supported only for:

 `Visual Studio 14 2015 Win64`
 Specify target platform `x64`.
 `Visual Studio 14 2015 ARM`
 Specify target platform `ARM`.
 
 
 Regards,
 
 Juan
 
 
 On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza 
  wrote:
> cl from visual studio 2017.
> 
> Em ter, 17 de set de 2019 03:26, Stéphane Ancelot 
>  escreveu:
>> Hi,

>> That first depends on which compiler you will use ?

>> Regards,

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Joao Pedro Abreu De Souza]

Thanks, I'll check it out.

The toolchain file, as is, can generate ninja builds that can be used to
generate a executable, but when I execute them, he say :

```
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/amd64_x86/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/amd64_x86/cl.exe -- broken
CMake Error at C:/Program
Files/CMake/share/cmake-3.15/Modules/CMakeTestCCompiler.cmake:60 (message):
  The C compiler

"C:/Program Files (x86)/Microsoft Visual Studio
12.0/VC/bin/amd64_x86/cl.exe"

  is not able to compile a simple test program.

  It fails with the following output:

Change Dir:
C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/CMakeTmp

Run Build Command(s):C:/ProgramData/chocolatey/bin/ninja.exe cmTC_0dfb4
&& [1/2] Building C object CMakeFiles\cmTC_0dfb4.dir\testCCompiler.c.obj
FAILED: CMakeFiles/cmTC_0dfb4.dir/testCCompiler.c.obj
"C:\PROGRA~2\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\cl.exe"
 -o CMakeFiles\cmTC_0dfb4.dir\testCCompiler.c.obj   -c testCCompiler.c
ninja: build stopped: subcommand failed.





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:2 (project)
```

Em ter, 17 de set de 2019 às 16:02, Juan Sanchez 
escreveu:

> From my brief research, it looks like the Microsoft version of CMake may
> have Ninja support.
>
>
> https://devblogs.microsoft.com/cppblog/cmake-support-in-visual-studio-whats-new-in-2017-15-3-update/
>
>
> Regards,
>
> Juan
>
> On Tue, Sep 17, 2019 at 1:36 PM Joao Pedro Abreu De Souza <
> jp_ab...@id.uff.br> wrote:
>
>> So, only the Visual Studio generator use the Arch option? I try generate
>> ninja build, but cmake(3.15.3) and the answer was
>>
>> ```
>> $ cmake -B build -S . -G "Ninja" -A Win32
>> CMake Error at CMakeLists.txt:2 (project):
>>   Generator
>>
>> Ninja
>>
>>   does not support platform specification, but platform
>>
>> Win32
>>
>>   was specified.
>>
>>
>> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
>> CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
>> -- Configuring incomplete, errors occurred!
>> See also
>> "C:/Users/jpabreu/Desktop/testCMAKE/build/CMakeFiles/CMakeOutput.log".
>> ```
>>
>> Em ter, 17 de set de 2019 às 14:00, Juan Sanchez <
>> juan.e.sanc...@gmail.com> escreveu:
>>
>>> Hello,
>>>
>>> My impression that targeting 32 bit depends on what generator you are
>>> using.
>>>
>>> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html
>>>
>>> It looks like cmake now has:
>>>
>>>- cmake -G "Visual Studio 15 2017" -A Win32
>>>- cmake -G "Visual Studio 15 2017" -A x64
>>>
>>> It used to be that the default target platform was Win32, and  you had
>>> to specify Win64 in the generator string to target a 64 bit build.  For
>>> example with Visual Studio 2015
>>>
>>>
>>> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html
>>>
>>> For compatibility with CMake versions prior to 3.1, one may specify a
>>> target platform name optionally at the end of the generator name. This is
>>> supported only for:
>>> Visual Studio 14 2015 Win64Specify target platform x64.Visual Studio 14
>>> 2015 ARMSpecify target platform ARM.
>>>
>>>
>>> Regards,
>>>
>>> Juan
>>>
>>>
>>> On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza <
>>> jp_ab...@id.uff.br> wrote:
>>>
 cl from visual studio 2017.

 Em ter, 17 de set de 2019 03:26, Stéphane Ancelot <
 sance...@numalliance.com> escreveu:

> Hi,
>
> That first depends on which compiler you will use ?
>
> Regards,
>
> S.Ancelot
> Le 16/09/2019 à 22:32, Joao Pedro Abreu De Souza a écrit :
>
> Hi guys. I am trying to generate,using cmake, a executable with target
> Windows 32 bits using Windows 64 bits, but cannot find a standard 
> toolchain
> file (I find to Linux, to Android, but can't find to Windows 32 bits) to
> build. Do you know some repository of toolchain files that has Windows 32
> bits from Windows 64 bits? Or maybe someone has a standard toolchain file
> to this type of thing.
>
> Thanks in advance.
>
> --

 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 

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Juan Sanchez]

>From my brief research, it looks like the Microsoft version of CMake may
have Ninja support.

https://devblogs.microsoft.com/cppblog/cmake-support-in-visual-studio-whats-new-in-2017-15-3-update/


Regards,

Juan

On Tue, Sep 17, 2019 at 1:36 PM Joao Pedro Abreu De Souza <
jp_ab...@id.uff.br> wrote:

> So, only the Visual Studio generator use the Arch option? I try generate
> ninja build, but cmake(3.15.3) and the answer was
>
> ```
> $ cmake -B build -S . -G "Ninja" -A Win32
> CMake Error at CMakeLists.txt:2 (project):
>   Generator
>
> Ninja
>
>   does not support platform specification, but platform
>
> Win32
>
>   was specified.
>
>
> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
> CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
> -- Configuring incomplete, errors occurred!
> See also
> "C:/Users/jpabreu/Desktop/testCMAKE/build/CMakeFiles/CMakeOutput.log".
> ```
>
> Em ter, 17 de set de 2019 às 14:00, Juan Sanchez 
> escreveu:
>
>> Hello,
>>
>> My impression that targeting 32 bit depends on what generator you are
>> using.
>>
>> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html
>>
>> It looks like cmake now has:
>>
>>- cmake -G "Visual Studio 15 2017" -A Win32
>>- cmake -G "Visual Studio 15 2017" -A x64
>>
>> It used to be that the default target platform was Win32, and  you had to
>> specify Win64 in the generator string to target a 64 bit build.  For
>> example with Visual Studio 2015
>>
>>
>> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html
>>
>> For compatibility with CMake versions prior to 3.1, one may specify a
>> target platform name optionally at the end of the generator name. This is
>> supported only for:
>> Visual Studio 14 2015 Win64Specify target platform x64.Visual Studio 14
>> 2015 ARMSpecify target platform ARM.
>>
>>
>> Regards,
>>
>> Juan
>>
>>
>> On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza <
>> jp_ab...@id.uff.br> wrote:
>>
>>> cl from visual studio 2017.
>>>
>>> Em ter, 17 de set de 2019 03:26, Stéphane Ancelot <
>>> sance...@numalliance.com> escreveu:
>>>
 Hi,

 That first depends on which compiler you will use ?

 Regards,

 S.Ancelot
 Le 16/09/2019 à 22:32, Joao Pedro Abreu De Souza a écrit :

 Hi guys. I am trying to generate,using cmake, a executable with target
 Windows 32 bits using Windows 64 bits, but cannot find a standard toolchain
 file (I find to Linux, to Android, but can't find to Windows 32 bits) to
 build. Do you know some repository of toolchain files that has Windows 32
 bits from Windows 64 bits? Or maybe someone has a standard toolchain file
 to this type of thing.

 Thanks in advance.

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

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Joao Pedro Abreu De Souza]

So, only the Visual Studio generator use the Arch option? I try generate
ninja build, but cmake(3.15.3) and the answer was

```
$ cmake -B build -S . -G "Ninja" -A Win32
CMake Error at CMakeLists.txt:2 (project):
  Generator

Ninja

  does not support platform specification, but platform

Win32

  was specified.


CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
See also
"C:/Users/jpabreu/Desktop/testCMAKE/build/CMakeFiles/CMakeOutput.log".
```

Em ter, 17 de set de 2019 às 14:00, Juan Sanchez 
escreveu:

> Hello,
>
> My impression that targeting 32 bit depends on what generator you are
> using.
>
> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html
>
> It looks like cmake now has:
>
>- cmake -G "Visual Studio 15 2017" -A Win32
>- cmake -G "Visual Studio 15 2017" -A x64
>
> It used to be that the default target platform was Win32, and  you had to
> specify Win64 in the generator string to target a 64 bit build.  For
> example with Visual Studio 2015
>
>
> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html
>
> For compatibility with CMake versions prior to 3.1, one may specify a
> target platform name optionally at the end of the generator name. This is
> supported only for:
> Visual Studio 14 2015 Win64Specify target platform x64.Visual Studio 14
> 2015 ARMSpecify target platform ARM.
>
>
> Regards,
>
> Juan
>
>
> On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza <
> jp_ab...@id.uff.br> wrote:
>
>> cl from visual studio 2017.
>>
>> Em ter, 17 de set de 2019 03:26, Stéphane Ancelot <
>> sance...@numalliance.com> escreveu:
>>
>>> Hi,
>>>
>>> That first depends on which compiler you will use ?
>>>
>>> Regards,
>>>
>>> S.Ancelot
>>> Le 16/09/2019 à 22:32, Joao Pedro Abreu De Souza a écrit :
>>>
>>> Hi guys. I am trying to generate,using cmake, a executable with target
>>> Windows 32 bits using Windows 64 bits, but cannot find a standard toolchain
>>> file (I find to Linux, to Android, but can't find to Windows 32 bits) to
>>> build. Do you know some repository of toolchain files that has Windows 32
>>> bits from Windows 64 bits? Or maybe someone has a standard toolchain file
>>> to this type of thing.
>>>
>>> Thanks in advance.
>>>
>>> --
>>
>> 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

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Guy Mac]

AFAIK you can set the generator in a CMakeSettings.json file if you are 
using MSVC.


https://docs.microsoft.com/en-us/cpp/build/cmakesettings-reference?view=vs-2019

On 9/17/2019 10:00 AM, Juan Sanchez wrote:

Hello,

My impression that targeting 32 bit depends on what generator you are 
using.

https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html

It looks like cmake now has:

  * |cmake -G "Visual Studio 15 2017" -A Win32|
  * |cmake -G "Visual Studio 15 2017" -A x64|

It used to be that the default target platform was Win32, and  you had 
to specify Win64 in the generator string to target a 64 bit build.  
For example with Visual Studio 2015


https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html

For compatibility with CMake versions prior to 3.1, one may specify a 
target platform name optionally at the end of the generator name. This 
is supported only for:


|Visual Studio 14 2015 Win64|
Specify target platform |x64|.
|Visual Studio 14 2015 ARM|
Specify target platform |ARM|.



Regards,

Juan


On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza 
mailto:jp_ab...@id.uff.br>> wrote:


cl from visual studio 2017.

Em ter, 17 de set de 2019 03:26, Stéphane Ancelot
mailto:sance...@numalliance.com>> escreveu:

Hi,

That first depends on which compiler you will use ?

Regards,

S.Ancelot

Le 16/09/2019 à 22:32, Joao Pedro Abreu De Souza a écrit :

Hi guys. I am trying to generate,using cmake, a executable
with target Windows 32 bits using Windows 64 bits, but cannot
find a standard toolchain file (I find to Linux, to Android,
but can't find to Windows 32 bits) to build. Do you know some
repository of toolchain files that has Windows 32 bits from
Windows 64 bits? Or maybe someone has a standard toolchain
file to this type of thing.

Thanks in advance.

-- 


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

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Juan Sanchez]

Hello,

My impression that targeting 32 bit depends on what generator you are using.
https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html

It looks like cmake now has:

   - cmake -G "Visual Studio 15 2017" -A Win32
   - cmake -G "Visual Studio 15 2017" -A x64

It used to be that the default target platform was Win32, and  you had to
specify Win64 in the generator string to target a 64 bit build.  For
example with Visual Studio 2015

https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html

For compatibility with CMake versions prior to 3.1, one may specify a
target platform name optionally at the end of the generator name. This is
supported only for:
Visual Studio 14 2015 Win64Specify target platform x64.Visual Studio 14 2015
 ARMSpecify target platform ARM.


Regards,

Juan


On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza <
jp_ab...@id.uff.br> wrote:

> cl from visual studio 2017.
>
> Em ter, 17 de set de 2019 03:26, Stéphane Ancelot <
> sance...@numalliance.com> escreveu:
>
>> Hi,
>>
>> That first depends on which compiler you will use ?
>>
>> Regards,
>>
>> S.Ancelot
>> Le 16/09/2019 à 22:32, Joao Pedro Abreu De Souza a écrit :
>>
>> Hi guys. I am trying to generate,using cmake, a executable with target
>> Windows 32 bits using Windows 64 bits, but cannot find a standard toolchain
>> file (I find to Linux, to Android, but can't find to Windows 32 bits) to
>> build. Do you know some repository of toolchain files that has Windows 32
>> bits from Windows 64 bits? Or maybe someone has a standard toolchain file
>> to this type of thing.
>>
>> Thanks in advance.
>>
>> --
>
> 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

Re: [CMake] system runtime library file does not exist (warning)

[Juan Sanchez]

Hello,

Somewhat related to your issue, is that newer versions of the Intel MKL are
now free for use:
https://software.intel.com/en-us/articles/free-ipsxe-tools-and-libraries

Free Intel Performance Libraries
 for *Everyone*

*Free for all, no royalties, no restrictions on company or project size,
access to current & older versions of libraries (only current version for
Intel® MPI), Forum Support.*

Regards,

Juan

On Tue, Sep 17, 2019 at 5:46 AM Ilias Miroslav, doc. RNDr., PhD. <
miroslav.il...@umb.sk> wrote:

> Hello,
>
> I have recent CMake 3.15.2 and old MKL library 11.1.
>
> Upon configuration cmake is issuing warnings due to faulty determined
> folder of general name  FOLDER_lin (proper name is without lin):
>
> CMake Warning at
> /home/milias/bin/cmake/cmake-3.15.2-Linux-x86_64/share/cmake-3.15/Modules/InstallRequiredSystemLibraries.cmake:684
> (message):
>   system runtime library file does not exist:
>   '/mnt/apps/intel/composer_xe_2013_sp1.1.106/compiler/lib/intel64*_lin*
> /irml'
> Call Stack (most recent call first):
>   cmake/custom/cpack-dirac.cmake:1 (include)
>   CMakeLists.txt:85 (include)
>
> while proper MKL folder is:
>
> ls /mnt/apps/intel/composer_xe_2013_sp1.1.106/compiler/lib/intel64/
> cilk_db.so* libcilkrts.so.5*libcomposerxe_rdmgr_2.1.so*
>  libimf.so*  libistrconv.so*
> codecov_libFNP.so*  libcomposerxe_boost_date_time_1.34.so*
> libdecimal.a*libintlc.so*  libmatmul.a*
> crt/  libcomposerxe_boost_filesystem_1.34.so*  libicaf.so*
>  libintlc.so.5* liboffload.so*
> for_main.o* libcomposerxe_boost_regex_1.34.so*  libifcore.a*
>  libiomp5.a*  liboffload.so.5*
> icc_libFNP.so* libcomposerxe_boost_system_1.34.so*  libifcore.so*
>libiomp5.dbg*  libomp_db.so*
> icpc_libFNP.so* libcomposerxe_boost_thread_1.34.so*
>  libifcore.so.5*libiomp5.so*  libpdbx.a*
> ifort_libFNP.so*libcomposerxe_cfgmgr_2.4.so*  libifcore_pic.a*
>  libiompstubs5.a*   libpdbx.so*
> init.o*  libcomposerxe_clpt_3.1.so*   libifcoremt.a*
>  libiompstubs5.so*  libpdbx.so.5*
> irml/  libcomposerxe_cpil_2.10.so*   libifcoremt.so*
>  libipgo.a*  libpdbxinst.a*
> libbfp754.a* libcomposerxe_gen_helpers_core_2.3.so*
> libifcoremt.so.5*libirc.a*  libsvml.a*
> libchkp.so* libcomposerxe_gen_helpers_das_2.3.so*
>  libifcoremt_pic.alibirc.so*  libsvml.so*
> libchkpwrap.a* libcomposerxe_libxml_2.7.so*  libifport.a*
>  libirc_s.a*  locale/
> libchkpwrap_w.a*libcomposerxe_msngr_cmd_2.4.so*  libifport.so*
>  libirng.a*  ofldbegin.o*
> libcilkrts.a* libcomposerxe_msngr_reader_2.4.so*  libifport.so.5*
>libirng.so*  ofldend.o
> libcilkrts.so* libcomposerxe_msngr_util_2.4.so*  libimf.a*
> libistrconv.a* tselect_libFNP.so*
>
> This is only warning, maybe InstallRequiredSystemLibraries.cmake could be
> updated for that.
>
> Best,
>
> Miro
> --
>
> 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

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Albrecht Schlosser]

On 9/17/19 2:17 PM Joao Pedro Abreu De Souza wrote:

cl from visual studio 2017.

Em ter, 17 de set de 2019 03:26, Stéphane Ancelot 
mailto:sance...@numalliance.com>> escreveu:


Hi,

That first depends on which compiler you will use ?

Regards,

S.Ancelot

Le 16/09/2019 à 22:32, Joao Pedro Abreu De Souza a écrit :

Hi guys. I am trying to generate,using cmake, a executable with
target Windows 32 bits using Windows 64 bits, but cannot find a
standard toolchain file (I find to Linux, to Android, but can't
find to Windows 32 bits) to build. Do you know some repository of
toolchain files that has Windows 32 bits from Windows 64 bits? Or
maybe someone has a standard toolchain file to this type of thing.


Well, I don't have a toolchain file for your compiler, but maybe my 
toolchain file for cross compilation under Linux for Windows (64-bit) 
can help. You'll need to adjust compiler and paths...


$ cat mingw-w64_toolchain.cmake
# CMake Toolchain File for MinGW-w64 (64-bit) Cross Compilation

# the name of the target operating system
set(CMAKE_SYSTEM_NAME Windows)

# which tools to use
set(CMAKE_C_COMPILER   /usr/bin/x86_64-w64-mingw32-gcc)
set(CMAKE_CXX_COMPILER /usr/bin/x86_64-w64-mingw32-g++)

# here is where the target environment located
set(CMAKE_FIND_ROOT_PATH  /usr/x86_64-w64-mingw32)

# adjust the default behavior of the FIND_XXX() commands:

# search programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)

# search headers and libraries in the target environment
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

set(CMAKE_INSTALL_PREFIX ${CMAKE_FIND_ROOT_PATH}/usr CACHE FILEPATH
   "install path prefix")

# initialize required linker flags
set(CMAKE_EXE_LINKER_FLAGS_INIT "-static-libgcc -static-libstdc++")

# end of toolchain file

HTH. YMMV
--

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.15.3-1067-ge6ddb57

[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  e6ddb57479a3620c712719c120a7337a84470d21 (commit)
   via  14fb0f3967f625264768dc9005e0b3e9191bd6d7 (commit)
   via  e82e4b03418e13c7e9d7062d81ba6510fd66be9b (commit)
   via  bd5006e8134a3ea5d949f9eedf139126af357820 (commit)
   via  3b409643bd0f69d38d91bba6b64250e48b276398 (commit)
   via  8c83f39a90b98a65a067813db1841ebcd6e0a400 (commit)
   via  445ff5ccdf7f888b48d12076fb42ca856482779f (commit)
  from  42a20ef79b86090b65de9836158db2a59c837e69 (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=e6ddb57479a3620c712719c120a7337a84470d21
commit e6ddb57479a3620c712719c120a7337a84470d21
Merge: 14fb0f3 3b40964
Author: Brad King 
AuthorDate: Tue Sep 17 15:11:55 2019 +
Commit: Kitware Robot 
CommitDate: Tue Sep 17 11:12:08 2019 -0400

Merge topic 'byproduct-collapse-full-path'

3b409643bd Byproducts: Add test for collapsing of full paths in byproducts
445ff5ccdf Byproducts: collapse full paths of custom target byproducts

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=14fb0f3967f625264768dc9005e0b3e9191bd6d7
commit 14fb0f3967f625264768dc9005e0b3e9191bd6d7
Merge: e82e4b0 8c83f39
Author: Brad King 
AuthorDate: Tue Sep 17 15:10:08 2019 +
Commit: Kitware Robot 
CommitDate: Tue Sep 17 11:11:06 2019 -0400

Merge topic 'smart_ptr/cmSourceFile'

8c83f39a90 cmSourceFile: use unique_ptr for CustomCommand

Acked-by: Kitware Robot 
Acked-by: Kyle Edwards 
Merge-request: !3815

diff --cc Source/cmMakefile.cxx
index 88d03f9,6961e8e..f35b999
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@@ -13,8 -10,13 +13,10 @@@
  #include 
  #include 
  #include 
 -#include 
 -#include 
  #include 
  
+ #include "cm_memory.hxx"
+ 
  #include "cmAlgorithms.h"
  #include "cmCommandArgumentParserHelper.h"
  #include "cmCustomCommand.h"

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e82e4b03418e13c7e9d7062d81ba6510fd66be9b
commit e82e4b03418e13c7e9d7062d81ba6510fd66be9b
Merge: 42a20ef bd5006e
Author: Brad King 
AuthorDate: Tue Sep 17 15:09:35 2019 +
Commit: Kitware Robot 
CommitDate: Tue Sep 17 11:09:56 2019 -0400

Merge topic 'iar-v850'

bd5006e813 IAR: Add v850 support

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd5006e8134a3ea5d949f9eedf139126af357820
commit bd5006e8134a3ea5d949f9eedf139126af357820
Author: Nico Mueller 
AuthorDate: Mon Sep 16 10:45:03 2019 +0200
Commit: Brad King 
CommitDate: Mon Sep 16 11:07:04 2019 -0400

IAR: Add v850 support

Add compiler identification for V850.

Issue: #17264

diff --git a/Modules/CMakePlatformId.h.in b/Modules/CMakePlatformId.h.in
index 542a6fe..95465ce 100644
--- a/Modules/CMakePlatformId.h.in
+++ b/Modules/CMakePlatformId.h.in
@@ -174,6 +174,9 @@
 # elif defined(__ICC430__)
 #  define ARCHITECTURE_ID "MSP430"
 
+# elif defined(__ICCV850__)
+#  define ARCHITECTURE_ID "V850"
+
 # else /* unknown architecture */
 #  define ARCHITECTURE_ID ""
 # endif
diff --git a/Modules/Compiler/IAR-C.cmake b/Modules/Compiler/IAR-C.cmake
index e03ce3f..9ad1ba0 100644
--- a/Modules/Compiler/IAR-C.cmake
+++ b/Modules/Compiler/IAR-C.cmake
@@ -60,6 +60,11 @@ elseif("${CMAKE_C_COMPILER_ARCHITECTURE_ID}" STREQUAL 
"MSP430")
   __compiler_check_default_language_standard(C 1.10 90 5.10 99)
   set(CMAKE_C_OUTPUT_EXTENSION ".r43")
 
+elseif("${CMAKE_C_COMPILER_ARCHITECTURE_ID}" STREQUAL "V850")
+  __compiler_iar_xlink(C)
+  __compiler_check_default_language_standard(C 1.10 90 4.10 99)
+  set(CMAKE_C_OUTPUT_EXTENSION ".r85")
+
 else()
   message(FATAL_ERROR "CMAKE_C_COMPILER_ARCHITECTURE_ID not detected. This 
should be automatic.")
 endif()
diff --git a/Modules/Compiler/IAR-CXX.cmake b/Modules/Compiler/IAR-CXX.cmake
index e8f1142..549d242 100644
--- a/Modules/Compiler/IAR-CXX.cmake
+++ b/Modules/Compiler/IAR-CXX.cmake
@@ -68,6 +68,10 @@ elseif("${CMAKE_CXX_COMPILER_ARCHITECTURE_ID}" STREQUAL 
"MSP430")
   __compiler_check_default_language_standard(CXX 5.10 98)
   set(CMAKE_CXX_OUTPUT_EXTENSION ".r43")
 
+elseif("${CMAKE_CXX_COMPILER_ARCHITECTURE_ID}" STREQUAL "V850")
+  __compiler_iar_xlink(CXX)
+  __compiler_check_default_language_standard(CXX 1.10 98)
+  set(CMAKE_C_OUTPUT_EXTENSION ".r85")
 else()
   message(FATAL_ERROR "CMAKE_CXX_COMPILER_ARCHITECTURE_ID not detected. This 
should be automatic." )
 endif()
diff --git a/Modules/Compiler/IAR-DetermineCompiler.cmake 

[Cmake-commits] CMake branch, master, updated. v3.15.3-1060-g42a20ef

[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  42a20ef79b86090b65de9836158db2a59c837e69 (commit)
   via  35b580d6033395b491c73005d785aa2c456f734e (commit)
   via  0301a76bb464fc3231193c4f1c957327e8258d44 (commit)
   via  28cb86d7962b2a9b8e49dc62bccf6187761524d9 (commit)
  from  3bc1feae5fe044d796e4bcd932b7228c40fde230 (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=42a20ef79b86090b65de9836158db2a59c837e69
commit 42a20ef79b86090b65de9836158db2a59c837e69
Merge: 35b580d 28cb86d
Author: Brad King 
AuthorDate: Tue Sep 17 15:08:27 2019 +
Commit: Kitware Robot 
CommitDate: Tue Sep 17 11:08:43 2019 -0400

Merge topic 'allow-pkg-config-missing-libraries'

28cb86d796 FindPkgConfig: Allow libraries that can't be found with their 
full path

Acked-by: Kitware Robot 
Acked-by: Rolf Eike Beer 
Merge-request: !3781


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=35b580d6033395b491c73005d785aa2c456f734e
commit 35b580d6033395b491c73005d785aa2c456f734e
Merge: 3bc1fea 0301a76
Author: Brad King 
AuthorDate: Tue Sep 17 15:06:52 2019 +
Commit: Kitware Robot 
CommitDate: Tue Sep 17 11:07:08 2019 -0400

Merge topic 'remove-failing-modules-test'

0301a76bb4 FindEnvMod: Remove unreliable test case

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0301a76bb464fc3231193c4f1c957327e8258d44
commit 0301a76bb464fc3231193c4f1c957327e8258d44
Author: Chuck Atkins 
AuthorDate: Mon Sep 16 12:46:33 2019 -0400
Commit: Chuck Atkins 
CommitDate: Mon Sep 16 13:10:40 2019 -0400

FindEnvMod: Remove unreliable test case

There's no way to know that loading an arbitrary module doesn't pull in
extra dependent modules so the test case asserting that exactly one module
was loaded isn't valid.

diff --git a/Tests/FindEnvModules/EnvModules.cmake 
b/Tests/FindEnvModules/EnvModules.cmake
index 0c81bf2..21b0042 100644
--- a/Tests/FindEnvModules/EnvModules.cmake
+++ b/Tests/FindEnvModules/EnvModules.cmake
@@ -18,18 +18,16 @@ if(avail_mods)
 
   message("module list")
   env_module_list(loaded_mods)
+  set(mod0_found FALSE)
   foreach(mod IN LISTS loaded_mods)
 message("  ${mod}")
+if(NOT mod0_found AND mod MATCHES "^${mod0}")
+  set(mod0_found ${mod})
+endif()
   endforeach()
 
-  list(LENGTH loaded_mods num_loaded_mods)
-  message("Number of modules loaded: ${num_loaded_mods}")
-  if(NOT num_loaded_mods EQUAL 1)
-message(FATAL_ERROR "Exactly 1 module should be loaded.  Found 
${num_loaded_mods}")
-  endif()
-
-  list(GET loaded_mods 0 mod0_actual)
-  if(NOT (mod0_actual MATCHES "^${mod0}"))
-message(FATAL_ERROR "Loaded module does not match ${mod0}.  Actual: 
${mod0_actual}")
+  if(NOT mod0_found)
+message(FATAL_ERROR "Requested module ${mod0} not found in loaded modules")
   endif()
+  message("module ${mod0} found loaded as ${mod0_found}")
 endif()

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=28cb86d7962b2a9b8e49dc62bccf6187761524d9
commit 28cb86d7962b2a9b8e49dc62bccf6187761524d9
Author: Chuck Atkins 
AuthorDate: Wed Sep 4 12:36:34 2019 -0400
Commit: Chuck Atkins 
CommitDate: Mon Sep 16 13:02:08 2019 -0400

FindPkgConfig: Allow libraries that can't be found with their full path

pkg-config's .pc files can sometimes provide libraries that are visible to
the linker but not present in CMake's known search paths.  In the case
where CMake can find some, but not all of the library dependencies
provided in a .pc file, this allows them to be passed through as "-lfoo"
when the full path can't be found.

This also removes the test failure cases that occured because of this
scenario and adjsuts the remaining tests to account for not-found
libraries

diff --git a/Modules/FindPkgConfig.cmake b/Modules/FindPkgConfig.cmake
index 4c9af91..5162a44 100644
--- a/Modules/FindPkgConfig.cmake
+++ b/Modules/FindPkgConfig.cmake
@@ -214,7 +214,11 @@ function(_pkg_find_libs _prefix _no_cmake_path 
_no_cmake_environment_path)
  NAMES ${_pkg_search}
  ${_find_opts})
 mark_as_advanced(pkgcfg_lib_${_prefix}_${_pkg_search})
-list(APPEND _libs "${pkgcfg_lib_${_prefix}_${_pkg_search}}")
+if(pkgcfg_lib_${_prefix}_${_pkg_search})
+  list(APPEND _libs "${pkgcfg_lib_${_prefix}_${_pkg_search}}")
+else()
+  list(APPEND _libs ${_pkg_search})
+endif()
   endforeach()
 
   set(${_prefix}_LINK_LIBRARIES "${_libs}" PARENT_SCOPE)
diff --git 

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Joao Pedro Abreu De Souza]

cl from visual studio 2017.

Em ter, 17 de set de 2019 03:26, Stéphane Ancelot 
escreveu:

> Hi,
>
> That first depends on which compiler you will use ?
>
> Regards,
>
> S.Ancelot
> Le 16/09/2019 à 22:32, Joao Pedro Abreu De Souza a écrit :
>
> Hi guys. I am trying to generate,using cmake, a executable with target
> Windows 32 bits using Windows 64 bits, but cannot find a standard toolchain
> file (I find to Linux, to Android, but can't find to Windows 32 bits) to
> build. Do you know some repository of toolchain files that has Windows 32
> bits from Windows 64 bits? Or maybe someone has a standard toolchain file
> to this type of thing.
>
> Thanks in advance.
>
>
-- 

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] system runtime library file does not exist (warning)

[Ilias Miroslav, doc. RNDr., PhD.]

Hello,

I have recent CMake 3.15.2 and old MKL library 11.1.

Upon configuration cmake is issuing warnings due to faulty determined folder of 
general name  FOLDER_lin (proper name is without lin):

CMake Warning at 
/home/milias/bin/cmake/cmake-3.15.2-Linux-x86_64/share/cmake-3.15/Modules/InstallRequiredSystemLibraries.cmake:684
 (message):
  system runtime library file does not exist:
  '/mnt/apps/intel/composer_xe_2013_sp1.1.106/compiler/lib/intel64_lin/irml'
Call Stack (most recent call first):
  cmake/custom/cpack-dirac.cmake:1 (include)
  CMakeLists.txt:85 (include)

while proper MKL folder is:

ls /mnt/apps/intel/composer_xe_2013_sp1.1.106/compiler/lib/intel64/
cilk_db.so* libcilkrts.so.5*libcomposerxe_rdmgr_2.1.so*  libimf.so* 
 libistrconv.so*
codecov_libFNP.so*  libcomposerxe_boost_date_time_1.34.so*   libdecimal.a*
libintlc.so*  libmatmul.a*
crt/  libcomposerxe_boost_filesystem_1.34.so*  libicaf.so*
libintlc.so.5* liboffload.so*
for_main.o* libcomposerxe_boost_regex_1.34.so*  libifcore.a*
libiomp5.a*  liboffload.so.5*
icc_libFNP.so* libcomposerxe_boost_system_1.34.so*  libifcore.so*
libiomp5.dbg*  libomp_db.so*
icpc_libFNP.so* libcomposerxe_boost_thread_1.34.so*  libifcore.so.5*
libiomp5.so*  libpdbx.a*
ifort_libFNP.so*libcomposerxe_cfgmgr_2.4.so*  libifcore_pic.a*
libiompstubs5.a*   libpdbx.so*
init.o*  libcomposerxe_clpt_3.1.so*   libifcoremt.a*
libiompstubs5.so*  libpdbx.so.5*
irml/  libcomposerxe_cpil_2.10.so*   libifcoremt.so*libipgo.a*  
libpdbxinst.a*
libbfp754.a* libcomposerxe_gen_helpers_core_2.3.so*   libifcoremt.so.5*
libirc.a*  libsvml.a*
libchkp.so* libcomposerxe_gen_helpers_das_2.3.so*libifcoremt_pic.a
libirc.so*  libsvml.so*
libchkpwrap.a* libcomposerxe_libxml_2.7.so*  libifport.a*
libirc_s.a*  locale/
libchkpwrap_w.a*libcomposerxe_msngr_cmd_2.4.so*  libifport.so*
libirng.a*  ofldbegin.o*
libcilkrts.a* libcomposerxe_msngr_reader_2.4.so*  libifport.so.5*
libirng.so*  ofldend.o
libcilkrts.so* libcomposerxe_msngr_util_2.4.so*  libimf.a* 
libistrconv.a* tselect_libFNP.so*

This is only warning, maybe InstallRequiredSystemLibraries.cmake could be 
updated for that.

Best,

Miro
-- 

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] toolchain file - cross-compiling windows-amd64->windows-x86

[Stéphane Ancelot]

Hi,

That first depends on which compiler you will use ?

Regards,

S.Ancelot

Le 16/09/2019 à 22:32, Joao Pedro Abreu De Souza a écrit :
Hi guys. I am trying to generate,using cmake, a executable with target 
Windows 32 bits using Windows 64 bits, but cannot find a standard 
toolchain file (I find to Linux, to Android, but can't find to Windows 
32 bits) to build. Do you know some repository of toolchain files that 
has Windows 32 bits from Windows 64 bits? Or maybe someone has a 
standard toolchain file to this type of thing.


Thanks in advance.

-- 

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.15.3-1056-g3bc1fea

[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  3bc1feae5fe044d796e4bcd932b7228c40fde230 (commit)
  from  1ac4e0ef1b29affc9e4f2cd86c4fc8c2252f2ab2 (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=3bc1feae5fe044d796e4bcd932b7228c40fde230
commit 3bc1feae5fe044d796e4bcd932b7228c40fde230
Author: Kitware Robot 
AuthorDate: Tue Sep 17 00:01:08 2019 -0400
Commit: Kitware Robot 
CommitDate: Tue Sep 17 00:01:08 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 2aef888..887d970 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 15)
-set(CMake_VERSION_PATCH 20190916)
+set(CMake_VERSION_PATCH 20190917)
 #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] toolchain file - cross-compiling windows-amd64->windows-x86

[Joao Pedro Abreu De Souza]

Hi guys. I am trying to generate,using cmake, a executable with target
Windows 32 bits using Windows 64 bits, but cannot find a standard toolchain
file (I find to Linux, to Android, but can't find to Windows 32 bits) to
build. Do you know some repository of toolchain files that has Windows 32
bits from Windows 64 bits? Or maybe someone has a standard toolchain file
to this type of thing.

Thanks in advance.
-- 

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] Packaging a directory with CPack RPM

[Eric Noulard]

Le lun. 16 sept. 2019 à 18:12, Ashish Sadanandan <
ashish.sadanan...@gmail.com> a écrit :

> On Thu, Sep 12, 2019 at 4:57 AM Eric Noulard 
> wrote:
> >
> >
> >
> > Le jeu. 12 sept. 2019 à 02:27, Ashish Sadanandan <
> ashish.sadanan...@gmail.com> a écrit :
>
> >
> > Now may be you can tell CPack to ignore some of you installed
> files/directory by using: CPACK_RPM_USER_FILELIST
> >
> https://cmake.org/cmake/help/v3.15/cpack_gen/rpm.html#cpack_gen:CPack%20RPM%20Generator
> >
>
> Sorry, I should've mentioned in the original email that the files are
> required, so ignoring is not what I want.
>

My answer wasn't clear, using   CPACK_RPM_USER_FILELIST enables you to
specify the de %file and/or %dir
directive you want and it thus make CPackRPM avoid using its ownn generated
file list  (i.e. ignore it).

You can somehow override the builtin file and dir discovery of CPack.

As the doc says:
"Since the CPack RPM generator is generating the list of files (and
directories) the user specified files of the
CPACK_RPM__USER_FILELIST list will be removed from the generated
list. If referring to directories do not add a trailing slash."

>> I'm not claiming this is the reason for CPack being slow, I came across
> this while investigating performance and if nothing else, this will result
> in a cleaner looking spec file.
> >
> >
> > For performance sake you can try CPACK_RPM_USER_BINARY_SPECFILE,
> CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE
> > and handcraft your "user" spec file in order to see if it helps the
> packaging performance.
> > and/or you can set CPACK_RPM_PACKAGE_DEBUG to 1 in order to get more
> timed traces of CPackRPM execution.
> >
>
> Thanks, this looks promising but I'm having trouble getting CPack to
> use my custom spec file. This is what I've added to my CMakeLists.txt
> so far (using cmake 3.6.3)
>


Then be sure to read the corresponding documentation:
https://cmake.org/cmake/help/v3.6/module/CPackRPM.html



> # We're already using component install
> set(CPACK_RPM_COMPONENT_INSTALL ON)
> set(CPACK_RPM_TESTS_FILE_NAME
>
> "${CPACK_PACKAGE_NAME}-tests-${CPACK_PACKAGE_VERSION}-${CPACK_RPM_PACKAGE_RELEASE}.${CMAKE_SYSTEM_PROCESSOR}.rpm"
> )
> install(DIRECTORY ${CMAKE_BINARY_DIR}/tests
> DESTINATION tests
> COMPONENT tests
> )
> set(CPACK_RPM_TESTS_USER_BINARY_SPECFILE
> "${CMAKE_CURRENT_SOURCE_DIR}/tests.spec"
> )
>
> But CPack is still generating a spec file for the tests RPM instead of
> using my spec file. I've even tried using an absolute path to the spec
> file but still the same behavior. What am I doing wrong?
>

Difficult to say without seeing your CMakeLists.txt or verbose CPack output.

Did you set those variables before or after include(CPack) ?
Those vars should be set *before*  include(CPack) otherwise they won't be
taken into account.

Did you try running CPack in debug mode:

cpack -D CPACK_RPM_PACKAGE_DEBUG=1 -G RPM

in order to have more verbose output?
-- 
Eric
-- 

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] Packaging a directory with CPack RPM

[Ashish Sadanandan]

On Thu, Sep 12, 2019 at 4:57 AM Eric Noulard  wrote:
>
>
>
> Le jeu. 12 sept. 2019 à 02:27, Ashish Sadanandan 
>  a écrit :
>>
>> Hello,
>> I'm using CPack to create RPMs for an application. I have this working but 
>> the CPack step is quite slow. While investigating this, I noticed that all 
>> files in a directory I'm packaging, which contains a large number of small 
>> files, is being listed in the spec file.
>>
>> For instance, say I have
>>
>> set(CPACK_PACKAGING_INSTALL_PREFIX /opt/myapp)
>> install(DIRECTORY ${CMAKE_BINARY_DIR}/myapp/foo
>> DESTINATION foo
>> COMPONENT myapp
>> )
>>
>> In the %files section I see
>>
>> %files
>> %dir /opt/myapp/foo
>> " /opt/myapp/foo/file1"
>> " /opt/myapp/foo/file2"
>> ...
>> " /opt/myapp/foo/file6"
>>
>> If I were writing the spec file by hand, this entire section could be 
>> replaced by a single line
>>
>> %files
>> /opt/myapp/foo
>
>
> CPack has no idea that the list of files are coming from an installed 
> *directory*, because CPack is not doing the install CMake is.
> Thus CPackRPM and other CPack generators collect all installed bits inside a 
> given [temporary] prefix directory.
>
> Now may be you can tell CPack to ignore some of you installed files/directory 
> by using: CPACK_RPM_USER_FILELIST
>  
> https://cmake.org/cmake/help/v3.15/cpack_gen/rpm.html#cpack_gen:CPack%20RPM%20Generator
>

Sorry, I should've mentioned in the original email that the files are
required, so ignoring is not what I want.

>
>>
>> RPM will package all files within the directory if you specify the directory 
>> under %files 
>> (http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html - the 
>> "The %dir Directive" section)
>> Is there an option to list just the directory instead of recursively listing 
>> all contained files within the directory?
>
>
> AFAIK, No there is not.
>
>
>> I'm not claiming this is the reason for CPack being slow, I came across this 
>> while investigating performance and if nothing else, this will result in a 
>> cleaner looking spec file.
>
>
> For performance sake you can try CPACK_RPM_USER_BINARY_SPECFILE, 
> CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE
> and handcraft your "user" spec file in order to see if it helps the packaging 
> performance.
> and/or you can set CPACK_RPM_PACKAGE_DEBUG to 1 in order to get more timed 
> traces of CPackRPM execution.
>

Thanks, this looks promising but I'm having trouble getting CPack to
use my custom spec file. This is what I've added to my CMakeLists.txt
so far (using cmake 3.6.3)

# We're already using component install
set(CPACK_RPM_COMPONENT_INSTALL ON)
set(CPACK_RPM_TESTS_FILE_NAME

"${CPACK_PACKAGE_NAME}-tests-${CPACK_PACKAGE_VERSION}-${CPACK_RPM_PACKAGE_RELEASE}.${CMAKE_SYSTEM_PROCESSOR}.rpm"
)
install(DIRECTORY ${CMAKE_BINARY_DIR}/tests
DESTINATION tests
COMPONENT tests
)
set(CPACK_RPM_TESTS_USER_BINARY_SPECFILE
"${CMAKE_CURRENT_SOURCE_DIR}/tests.spec"
)

But CPack is still generating a spec file for the tests RPM instead of
using my spec file. I've even tried using an absolute path to the spec
file but still the same behavior. What am I doing wrong?


>
> --
> Eric

Thanks so much for your help,
Ashish.
-- 

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.15.3-1055-g1ac4e0e

[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  1ac4e0ef1b29affc9e4f2cd86c4fc8c2252f2ab2 (commit)
   via  f30523d090b343c7eff3083b8f12e3dcd4755cba (commit)
  from  7c47894b459c0f71ebe32b64a619f290df6bcf44 (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=1ac4e0ef1b29affc9e4f2cd86c4fc8c2252f2ab2
commit 1ac4e0ef1b29affc9e4f2cd86c4fc8c2252f2ab2
Merge: 7c47894 f30523d
Author: Brad King 
AuthorDate: Mon Sep 16 14:25:33 2019 +
Commit: Kitware Robot 
CommitDate: Mon Sep 16 10:25:53 2019 -0400

Merge topic 'tidy-deprecated-headers'

f30523d090 clang-tidy: modernize-deprecated-headers

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

diff --cc Source/cmFLTKWrapUICommand.cxx
index 5094c3c,afeaf37..654714e
--- a/Source/cmFLTKWrapUICommand.cxx
+++ b/Source/cmFLTKWrapUICommand.cxx
@@@ -2,10 -2,9 +2,10 @@@
 file Copyright.txt or https://cmake.org/licensing for details.  */
  #include "cmFLTKWrapUICommand.h"
  
- #include 
+ #include 
  
  #include "cmCustomCommandLines.h"
 +#include "cmExecutionStatus.h"
  #include "cmMakefile.h"
  #include "cmRange.h"
  #include "cmSourceFile.h"

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f30523d090b343c7eff3083b8f12e3dcd4755cba
commit f30523d090b343c7eff3083b8f12e3dcd4755cba
Author: Regina Pfeifer 
AuthorDate: Fri Sep 6 22:58:06 2019 +0200
Commit: Brad King 
CommitDate: Mon Sep 16 10:11:13 2019 -0400

clang-tidy: modernize-deprecated-headers

diff --git a/.clang-tidy b/.clang-tidy
index a240e9c..a520679 100644
--- a/.clang-tidy
+++ b/.clang-tidy
@@ -11,7 +11,6 @@ misc-*,\
 -misc-static-assert,\
 modernize-*,\
 -modernize-avoid-c-arrays,\
--modernize-deprecated-headers,\
 -modernize-use-nodiscard,\
 -modernize-use-noexcept,\
 -modernize-use-transparent-functors,\
diff --git a/Source/CPack/IFW/cmCPackIFWInstaller.cxx 
b/Source/CPack/IFW/cmCPackIFWInstaller.cxx
index b4bfea7..2393279 100644
--- a/Source/CPack/IFW/cmCPackIFWInstaller.cxx
+++ b/Source/CPack/IFW/cmCPackIFWInstaller.cxx
@@ -13,8 +13,8 @@
 #include "cmXMLParser.h"
 #include "cmXMLWriter.h"
 
+#include 
 #include 
-#include 
 #include 
 
 cmCPackIFWInstaller::cmCPackIFWInstaller() = default;
diff --git a/Source/CPack/IFW/cmCPackIFWPackage.cxx 
b/Source/CPack/IFW/cmCPackIFWPackage.cxx
index 5fa8cce..9f2a443 100644
--- a/Source/CPack/IFW/cmCPackIFWPackage.cxx
+++ b/Source/CPack/IFW/cmCPackIFWPackage.cxx
@@ -13,9 +13,9 @@
 #include "cmTimestamp.h"
 #include "cmXMLWriter.h"
 
+#include 
 #include 
 #include 
-#include 
 #include 
 
 //-- CompareStruct ---
diff --git a/Source/CPack/IFW/cmCPackIFWRepository.cxx 
b/Source/CPack/IFW/cmCPackIFWRepository.cxx
index 8042167..82ddbdb 100644
--- a/Source/CPack/IFW/cmCPackIFWRepository.cxx
+++ b/Source/CPack/IFW/cmCPackIFWRepository.cxx
@@ -8,7 +8,7 @@
 #include "cmXMLParser.h"
 #include "cmXMLWriter.h"
 
-#include 
+#include 
 
 cmCPackIFWRepository::cmCPackIFWRepository()
   : Update(cmCPackIFWRepository::None)
diff --git a/Source/CPack/OSXScriptLauncher.cxx 
b/Source/CPack/OSXScriptLauncher.cxx
index 00d272c..b8f12fd 100644
--- a/Source/CPack/OSXScriptLauncher.cxx
+++ b/Source/CPack/OSXScriptLauncher.cxx
@@ -3,8 +3,9 @@
 #include "cmsys/FStream.hxx"
 #include "cmsys/Process.h"
 #include "cmsys/SystemTools.hxx"
+
+#include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/Source/CPack/cmCPackDebGenerator.cxx 
b/Source/CPack/cmCPackDebGenerator.cxx
index cefbc90..0e64b5a 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -13,10 +13,10 @@
 #include "cm_sys_stat.h"
 
 #include "cmsys/Glob.hxx"
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 
 namespace {
diff --git a/Source/CPack/cmCPackDragNDropGenerator.cxx 
b/Source/CPack/cmCPackDragNDropGenerator.cxx
index ca06b81..bedbfa8 100644
--- a/Source/CPack/cmCPackDragNDropGenerator.cxx
+++ b/Source/CPack/cmCPackDragNDropGenerator.cxx
@@ -12,9 +12,9 @@
 #include "cmsys/FStream.hxx"
 #include "cmsys/RegularExpression.hxx"
 #include 
+#include 
 #include 
 #include 
-#include 
 
 #include 
 
diff --git a/Source/CPack/cmCPackNSISGenerator.cxx 
b/Source/CPack/cmCPackNSISGenerator.cxx
index 8098edf..3f53186 100644
--- a/Source/CPack/cmCPackNSISGenerator.cxx
+++ b/Source/CPack/cmCPackNSISGenerator.cxx
@@ -14,10 +14,10 @@
 #include "cmsys/Directory.hxx"
 #include "cmsys/RegularExpression.hxx"
 #include 
+#include 
+#include 
 #include 
 #include 
-#include 
-#include 
 #include 
 
 /* NSIS uses different command line syntax on Windows and others */
diff --git 

[Cmake-commits] CMake branch, master, updated. v3.15.3-1053-g7c47894

[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  7c47894b459c0f71ebe32b64a619f290df6bcf44 (commit)
   via  1df2f8803b79c2e27d123de4f3f351bae824feef (commit)
   via  33588714832de46915542094c93a96096755fb55 (commit)
   via  7bf8eb78777e70d2d9c4dc7a3dd6875d82766592 (commit)
   via  5d28e361b709a781a131cb9d9da73f04484eff54 (commit)
   via  c16641607fcf85206b3faf67ae1e1bab173bf44d (commit)
   via  4fb29850ad325b70fb412d4fd596c0a0d627ae8b (commit)
  from  bfa2eaa617de778ecfb2a0678c9898605822260d (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=7c47894b459c0f71ebe32b64a619f290df6bcf44
commit 7c47894b459c0f71ebe32b64a619f290df6bcf44
Merge: 1df2f88 5d28e36
Author: Brad King 
AuthorDate: Mon Sep 16 14:16:57 2019 +
Commit: Kitware Robot 
CommitDate: Mon Sep 16 10:18:51 2019 -0400

Merge topic 'prepare-deferred-custom-command-creation'

5d28e361b7 add_custom_command: Move append functionality into class 
cmMakefile
4fb29850ad add_custom_command: Refactor setting implicit depends

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1df2f8803b79c2e27d123de4f3f351bae824feef
commit 1df2f8803b79c2e27d123de4f3f351bae824feef
Merge: 3358871 c166416
Author: Brad King 
AuthorDate: Mon Sep 16 14:16:40 2019 +
Commit: Kitware Robot 
CommitDate: Mon Sep 16 10:17:22 2019 -0400

Merge topic 'add_custom_command-genex-slash'

c16641607f add_custom_command: Delay slash conversion until after genex 
evaluation

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=33588714832de46915542094c93a96096755fb55
commit 33588714832de46915542094c93a96096755fb55
Merge: bfa2eaa 7bf8eb7
Author: Brad King 
AuthorDate: Mon Sep 16 14:15:23 2019 +
Commit: Kitware Robot 
CommitDate: Mon Sep 16 10:15:37 2019 -0400

Merge topic 'remove-unused-class'

7bf8eb7877 Remove unused cmInstallExportAndroidMKGenerator

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7bf8eb78777e70d2d9c4dc7a3dd6875d82766592
commit 7bf8eb78777e70d2d9c4dc7a3dd6875d82766592
Author: Tushar Maheshwari 
AuthorDate: Fri Sep 13 13:23:33 2019 -0400
Commit: Brad King 
CommitDate: Fri Sep 13 13:24:45 2019 -0400

Remove unused cmInstallExportAndroidMKGenerator

This class was added by commit 42ce9f1e71 (Add support for creating
prebuilt Android.mk files, 2016-07-12, v3.7.0-rc1~126^2) but not used.

diff --git a/Source/cmInstallExportAndroidMKGenerator.cxx 
b/Source/cmInstallExportAndroidMKGenerator.cxx
deleted file mode 100644
index e8de029..000
--- a/Source/cmInstallExportAndroidMKGenerator.cxx
+++ /dev/null
@@ -1,134 +0,0 @@
-
-/* Distributed under the OSI-approved BSD 3-Clause License.  See accompanying
-   file Copyright.txt or https://cmake.org/licensing for details.  */
-#include "cmInstallExportAndroidMKGenerator.h"
-
-#include 
-
-#include "cmExportInstallFileGenerator.h"
-#include "cmExportSet.h"
-#include "cmGeneratedFileStream.h"
-#include "cmGlobalGenerator.h"
-#include "cmInstallFilesGenerator.h"
-#include "cmInstallTargetGenerator.h"
-#include "cmLocalGenerator.h"
-#include "cmMakefile.h"
-#include "cmMessageType.h"
-
-cmInstallExportAndroidMKGenerator::cmInstallExportAndroidMKGenerator(
-  cmExportSet* exportSet, const char* destination,
-  const char* file_permissions, std::vector const& configurations,
-  const char* component, MessageLevel message, bool exclude_from_all,
-  const char* filename, const char* name_space, bool exportOld)
-  : cmInstallExportGenerator(exportSet, destination, file_permissions,
- configurations, component, message,
- exclude_from_all, filename, name_space, exportOld)
-{
-}
-
-cmInstallExportAndroidMKGenerator::~cmInstallExportAndroidMKGenerator()
-{
-}
-
-bool cmInstallExportAndroidMKGenerator::Compute(cmLocalGenerator* lg)
-{
-  this->LocalGenerator = lg;
-  this->ExportSet->Compute(lg);
-  return true;
-}
-
-void cmInstallExportAndroidMKGenerator::GenerateScript(std::ostream& os)
-{
-  // Skip empty sets.
-  if (ExportSet->GetTargetExports()->empty()) {
-std::ostringstream e;
-e << "INSTALL(EXPORT) given unknown export \"" << ExportSet->GetName()
-  << "\"";
-cmSystemTools::Error(e.str());
-return;
-  }
-
-  // Create the temporary directory in which to store the files.
-  this->ComputeTempDir();
-  cmSystemTools::MakeDirectory(this->TempDir.c_str());
-
-  // 

Re: [CMake] Preventing multiple definitions of metaObject methods

[Stephen Morris]

-Original Message-
From: Kyle Edwards  
Sent: 13 September 2019 16:54
To: Stephen Morris ; cmake@cmake.org
Subject: Re: [CMake] Preventing multiple definitions of metaObject methods

>Stephen,
>Could you post a minimally reproducible example with CMakeLists.txt and 
>accompanying source code? I am currently working on a Qt-based >project with 
>static libraries and have not encountered this issue.
>Kyle

It appears that the problem was due to a misunderstanding about how the PRIVATE 
keyword works in tergat_sources. I'd assumed that it should be used to identify 
the 'public headers' of a library (i.e. headers that should be included by the 
consumers of that library. It seems that this isn't the case, and even 'public' 
headers should be defined with the PRIVATE keyword.

Here are the simple demonstration files I wrote, four in all:

 myTest.h 

#ifndef MYTEST_HDR
#define MYTEST_HDR

class myTestWindow : public QMainWindow
{
Q_OBJECT
public:
myTestWindow()
virtual ~myTestWindow();

signals:
void readyToDisplay();

private slots:
void showTitle();
};

#endif

 myTest.cpp 

#include 
#include 
#include "myTest.h"

myTestWindow::myTestWindow() : QMainWindow(nullptr)
{
// Send the signal when ready to display
(QTimer::singleShot(0, this, ::showTitle));
}

myTestWindow::~myTestWindow()
{}

void myTestWindow::showTitle()
{
setWindowTitle(tr("This is a test window"));
}

#include "moc_myTest.cpp"

 main.cpp 

#include 
#include 

#include "myTest.h"

int main(int argc, char *argv[])
{
QApplication * app = new QApplication (argc, argv);
myTestWindow * win = new myTestWindow();
win->show();
app->exec();
return 0;
}

 CMakeLists.txt 

cmake_minimum_required (VERSION 3.14)
project(myTest LANGUAGES CXX)

find_package(Qt5 COMPONENTS Core Gui Widgets REQUIRED PATHS 
"C:\\Qt\\5.12.3\\msvc2017_64\\lib\\cmake\\Qt5" NO_DEFAULT_PATH)
set (CMAKE_AUTOMOC ON)
set (CMAKE_AUTORCC ON)
set (CMAKE_AUTOUIC ON)

add_library(myTest_Lib STATIC)
target_sources(myTest_Lib PRIVATE myTest.cpp)
target_sources(myTest_Lib PUBLIC myTest.h)
target_link_libraries(myTest_Lib PUBLIC Qt5::Core Qt5::Widgets)
set_target_properties(myTest_Lib PROPERTIES OUTPUT_NAME myTest)

add_executable(myTest_Exe main.cpp)
target_include_directories(myTest_Exe PRIVATE ${CMAKE_LIST_DIR})
target_link_libraries(myTest_Exe PRIVATE myTest_Lib)
set_target_properties(myTest_Exe PROPERTIES OUTPUT_NAME myTest 
VS_DEBUGGER_ENVIRONMENT  "PATH=C:\\Qt\\5.12.3\\msvc2017_64\\bin;%PATH%") 


Compiling and running them as given here, with the line 
"target_sources(myTest_Lib PUBLIC myTest.h)" in the MakeLists.txt file, my 
library compiles cleanly but I get an error saying "'QMainWindow': base class 
undefined" when trying to compile the executable application. This is because 
the compiler encounters the Q_OBJECT macro in myTest.h, generates a new 
moc_myTest.cpp, then because it can't see that the original moc_myTest.cpp was 
compiled within the library it includes it in its own mocs_compilation.cpp 
file. The error occurs when trying to compile this file, since moc_myTest.cpp 
does not include  anywhere.

If I try to fix this by adding the line "#include " just 
above the class declaration in myTest.h, then the error changes to a bunch of 
'multiple definition' errors, as I reported in my original question on Friday.

However, if I just change  "target_sources(myTest_Lib PUBLIC myTest.h)" to  
"target_sources(myTest_Lib PRIVATE myTest.h)", then all the problems go away; 
it doesn't even matter whether I leave the redundant '#include' in myTest.h, 
everything compiles cleanly either way.

It seems that the matter of static vs. shared libraries in my initial question 
was a red herring - in my previous work with shared libraries I haven't used 
either the PUBLIC or PRIVATE keywords, but merely supplied add_library with a 
list of undifferentiated source files. This problem turns out to have been 
entirely a matter of the use of the PUBLIC keyword. I have obviously been using 
it incorrectly, though this leads me to wonder what its purpose is, if not for 
this.  
-- 

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] Preventing multiple definitions of metaObject methods

[Stephen Morris]

-Original Message-
From: Kyle Edwards  
Sent: 13 September 2019 16:54
To: Stephen Morris ; cmake@cmake.org
Subject: Re: [CMake] Preventing multiple definitions of metaObject methods

>Stephen,
>Could you post a minimally reproducible example with CMakeLists.txt and 
>accompanying source code? I am currently working on a Qt-based >project with 
>static libraries and have not encountered this issue.
>Kyle

Thank you Kyle. I created a basic example as you suggested - a simple 
application linking a simple static library, both incorporating a header 
containing Q_OBJECT - and to my great chagrin it worked perfectly, without any 
compilation errors. 

So it seems that I've been wrong to suspect this as the cause of the 
multiple-definition errors in my main project. Clearly I must dig deeper, and 
if I find that the final explanation is of general interest then I shall report 
back.

Stephen.
-- 

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.15.3-1046-gbfa2eaa

[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  bfa2eaa617de778ecfb2a0678c9898605822260d (commit)
  from  c6ed04431988ac337ea21d74f035148b6c57f894 (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=bfa2eaa617de778ecfb2a0678c9898605822260d
commit bfa2eaa617de778ecfb2a0678c9898605822260d
Author: Kitware Robot 
AuthorDate: Mon Sep 16 00:01:06 2019 -0400
Commit: Kitware Robot 
CommitDate: Mon Sep 16 00:01:06 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index f41a727..2aef888 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 15)
-set(CMake_VERSION_PATCH 20190915)
+set(CMake_VERSION_PATCH 20190916)
 #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.15.3-1045-gc6ed044

[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  c6ed04431988ac337ea21d74f035148b6c57f894 (commit)
  from  80329771fec7c516540e1db29d971f8f28ed593b (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=c6ed04431988ac337ea21d74f035148b6c57f894
commit c6ed04431988ac337ea21d74f035148b6c57f894
Author: Kitware Robot 
AuthorDate: Sun Sep 15 00:01:05 2019 -0400
Commit: Kitware Robot 
CommitDate: Sun Sep 15 00:01:05 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 7384954..f41a727 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 15)
-set(CMake_VERSION_PATCH 20190914)
+set(CMake_VERSION_PATCH 20190915)
 #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] find_path and double symbolic link

[Kris Thielemans]

Hi all

 

I have a weird situation where find_file finds a file (which is a link to a
link), but find_path sets an empty variable.

 

find_path(CBLAS_INCLUDE_DIR cblas.h

PATHS /usr/include /usr/local/include )

message(STATUS "KT CBLAS_INCLUDE_DIR ${CBLAS_INCLUDE_DIR}")

find_file(CBLAS_INCLUDE cblas.h

PATHS /usr/include /usr/local/include  )

message(STATUS "KT CBLAS_INCLUDE ${CBLAS_INCLUDE}")

 

Running CMake gives

 

-- KT CBLAS_INCLUDE_DIR 

-- KT CBLAS_INCLUDE /usr/include/x86_64-linux-gnu/cblas.h

 

Checking the file I see

 

$ ls -l /usr/include/x86_64-linux-gnu/cblas.h

lrwxrwxrwx 1 root root 42 Mar 14  2019 /usr/include/x86_64-linux-gnu/cblas.h
-> /etc/alternatives/cblas.h-x86_64-linux-gnu

build$ ls -l /etc/alternatives/cblas.h-x86_64-linux-gnu

lrwxrwxrwx 1 root root 46 Mar 14  2019
/etc/alternatives/cblas.h-x86_64-linux-gnu ->
/usr/include/x86_64-linux-gnu/cblas-openblas.h

$ ls -l /usr/include/x86_64-linux-gnu/cblas-openblas.h

-rw-r--r-- 1 root root 45648 Sep 19  2017
/usr/include/x86_64-linux-gnu/cblas-openblas.h

 

Any ideas ? Is this expected?

 

I'm running CMake 3.13.1 on Ubuntu 18.04.

 

Kris

-- 

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.15.3-1044-g8032977

[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  80329771fec7c516540e1db29d971f8f28ed593b (commit)
  from  19bcdca93c3a05db12652677f8d0e310797bb375 (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=80329771fec7c516540e1db29d971f8f28ed593b
commit 80329771fec7c516540e1db29d971f8f28ed593b
Author: Kitware Robot 
AuthorDate: Sat Sep 14 00:01:05 2019 -0400
Commit: Kitware Robot 
CommitDate: Sat Sep 14 00:01:05 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index e9cca30..7384954 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 15)
-set(CMake_VERSION_PATCH 20190913)
+set(CMake_VERSION_PATCH 20190914)
 #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

Re: [cmake-developers] Proposal: Using smart pointers to own dynamically allocated memory

[Tushar Maheshwari]

I will do that. It's also easier for me to track the changes that way.

Regards,
Tushar

On Sat, Sep 14, 2019 at 12:04 AM Brad King  wrote:
>
> On 9/13/19 1:30 PM, Tushar Maheshwari wrote:
> > Thanks for the quick response.
> > I have my commits separated by file groups. I'll open small MRs
> > collecting the related groups.
>
> Thanks.  Please just keep a couple MRs open at a time so we don't
> overwhelm the CI builders.  After some are merged you can open more.
>
> -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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Proposal: Using smart pointers to own dynamically allocated memory

[Brad King via cmake-developers]

On 9/13/19 1:30 PM, Tushar Maheshwari wrote:
> Thanks for the quick response.
> I have my commits separated by file groups. I'll open small MRs
> collecting the related groups.

Thanks.  Please just keep a couple MRs open at a time so we don't
overwhelm the CI builders.  After some are merged you can open more.

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

Re: [cmake-developers] Proposal: Using smart pointers to own dynamically allocated memory

[Tushar Maheshwari]

Thanks for the quick response.
I have my commits separated by file groups. I'll open small MRs
collecting the related groups.
Please comment if the grouping is incorrect or if a commit/diff needs
to be moved to a different branch.

Thanks,
Tushar

On Fri, Sep 13, 2019 at 10:46 PM Brad King  wrote:
>
> On 9/13/19 12:58 PM, Kyle Edwards via cmake-developers wrote:
> > On Fri, 2019-09-13 at 22:08 +0530, Tushar Maheshwari wrote:
> >> I have pushed some sample commits to
> >> https://gitlab.kitware.com/tusharpm/cmake/commits/smart_mem.
> >>
> >> If this is something I can pursue, I would appreciate a review of my
> >> changes to better suit the project.
> >
> > We have already made lots of progress in replacing manual delete's with
> > std::unique_ptr's, and completing this modernization has been a goal of
> > ours since we switched to C++11. I would very strongly encourage you to
> > open a merge request with any progress you've made in this regard.
>
> Yes.  Your branch changes a lot of areas and there are several other
> rounds of refactoring going on so you may have trouble with conflicts.
> I suggest grouping the changes (e.g. ExportSet) and opening a MR with
> only one area.  Once that is merged open a new MR for another area.
>
> Thanks,
> -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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Proposal: Using smart pointers to own dynamically allocated memory

[Brad King via cmake-developers]

On 9/13/19 12:58 PM, Kyle Edwards via cmake-developers wrote:
> On Fri, 2019-09-13 at 22:08 +0530, Tushar Maheshwari wrote:
>> I have pushed some sample commits to
>> https://gitlab.kitware.com/tusharpm/cmake/commits/smart_mem.
>>
>> If this is something I can pursue, I would appreciate a review of my
>> changes to better suit the project.
> 
> We have already made lots of progress in replacing manual delete's with
> std::unique_ptr's, and completing this modernization has been a goal of
> ours since we switched to C++11. I would very strongly encourage you to
> open a merge request with any progress you've made in this regard.

Yes.  Your branch changes a lot of areas and there are several other
rounds of refactoring going on so you may have trouble with conflicts.
I suggest grouping the changes (e.g. ExportSet) and opening a MR with
only one area.  Once that is merged open a new MR for another area.

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

Re: [cmake-developers] Proposal: Using smart pointers to own dynamically allocated memory

[Kyle Edwards via cmake-developers]

On Fri, 2019-09-13 at 22:08 +0530, Tushar Maheshwari wrote:
> Hi,
> 
> I am a C++ developer and a modern-C++ enthusiast. In the interest of
> modernizing the codebase, I propose using smart pointers to handle
> dynamically allocated memory. I would like to get the feedback from
> the developers if this change is planned/attempted/desirable or
> inapplicable for CMake.
> 
> Currently, in the master branch (limiting to the Source directory):
> - delete expression appears 127 times (2 of those are false
> positives).
> $ grep -Er 'delete(\[\])? \S+;' Source | wc -l
>    127
> - cmDeleteAll function (a helper to delete a Range of objects) is
> used 40 times.
> $ grep -Er 'cmDeleteAll\(.+\);' Source | wc -l
> 40
> - [Skipping the `free` stats. I can investigate that if required.]
> 
> Many of these are great candidates for `std::unique_ptr`. This can
> reduce the destructors of many classes to default, and in some cases
> achieve the rule of zero. This aligns well with the "Resource
> management" section of the CppCoreGuidelines.
> However, it might be impractical to replace some occurrences, like
> the
> interfaces with C libraries.
> 
> I have pushed some sample commits to
> https://gitlab.kitware.com/tusharpm/cmake/commits/smart_mem.
> 
> One drawback I noticed while changing some members to use smart
> pointers is the boilerplate required to expose them to the callers.
> There might be a cleaner way than passing references to smart
> pointers. I would like to discuss those options also, if possible.
> 
> If this is something I can pursue, I would appreciate a review of my
> changes to better suit the project.

We have already made lots of progress in replacing manual delete's with
std::unique_ptr's, and completing this modernization has been a goal of
ours since we switched to C++11. I would very strongly encourage you to
open a merge request with any progress you've made in this regard.

Kyle
-- 

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

[cmake-developers] Proposal: Using smart pointers to own dynamically allocated memory

[Tushar Maheshwari]

Hi,

I am a C++ developer and a modern-C++ enthusiast. In the interest of
modernizing the codebase, I propose using smart pointers to handle
dynamically allocated memory. I would like to get the feedback from
the developers if this change is planned/attempted/desirable or
inapplicable for CMake.

Currently, in the master branch (limiting to the Source directory):
- delete expression appears 127 times (2 of those are false positives).
$ grep -Er 'delete(\[\])? \S+;' Source | wc -l
   127
- cmDeleteAll function (a helper to delete a Range of objects) is used 40 times.
$ grep -Er 'cmDeleteAll\(.+\);' Source | wc -l
40
- [Skipping the `free` stats. I can investigate that if required.]

Many of these are great candidates for `std::unique_ptr`. This can
reduce the destructors of many classes to default, and in some cases
achieve the rule of zero. This aligns well with the "Resource
management" section of the CppCoreGuidelines.
However, it might be impractical to replace some occurrences, like the
interfaces with C libraries.

I have pushed some sample commits to
https://gitlab.kitware.com/tusharpm/cmake/commits/smart_mem.

One drawback I noticed while changing some members to use smart
pointers is the boilerplate required to expose them to the callers.
There might be a cleaner way than passing references to smart
pointers. I would like to discuss those options also, if possible.

If this is something I can pursue, I would appreciate a review of my
changes to better suit the project.

Thanks,
Tushar
-- 

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] Preventing multiple definitions of metaObject methods

[Kyle Edwards via CMake]

On Fri, 2019-09-13 at 15:25 +, Stephen Morris wrote:
> Suppose I have a class that derives from QObject, and contains the
> Q_OBJECT macro in its header file. When I compile it using AUTOMOC
> enabled, a "moc_myClass.cpp" file is created; if I manually include
> that file at the end of my 'myClass.cpp" file, then the moc file will
> be compiled there, otherwise CMake will take matters into its own
> hands and compile it anyway.
> 
> Now suppose make my class into a static library. The static library
> now contains the object code generated when moc_myClass.cpp was
> compiled.
> 
> I now include my static library from an application. Unless I enable
> AUTOMOC again, then I get a compilation error when Q_OBJECT is
> encountered. If I do enable it, then CMake generates a new
> moc_myClass.cpp file and, since it can't see the place where it was
> included in myClass.cpp, it goes ahead and recompiles it, placing the
> object code alongside the application's other object code.
> 
> Now, when the application links in the static library, it finds two
> definitions of moc_myClass.cpp's object code, and gives a multiple
> definition error.
> 
> All the ways I've come up with so far to work around this are so
> hacky that I'm embarrassed to mention them. There must be a proper
> way to handle this situation. Please can someone advise me what it
> is?
> 
> (N.B. I've been doing this for years with dynamic libraries are never
> encountered a problem, presumably because there the application
> doesn't get to see the inner workings of the library's object code.
> This issue does seem to be specific to static libraries, of which I
> have little prior experience).

Stephen,

Could you post a minimally reproducible example with CMakeLists.txt and
accompanying source code? I am currently working on a Qt-based project
with static libraries and have not encountered this issue.

Kyle
-- 

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] Preventing multiple definitions of metaObject methods

[Stephen Morris]

Suppose I have a class that derives from QObject, and contains the Q_OBJECT 
macro in its header file. When I compile it using AUTOMOC enabled, a 
"moc_myClass.cpp" file is created; if I manually include that file at the end 
of my 'myClass.cpp" file, then the moc file will be compiled there, otherwise 
CMake will take matters into its own hands and compile it anyway.

Now suppose make my class into a static library. The static library now 
contains the object code generated when moc_myClass.cpp was compiled.

I now include my static library from an application. Unless I enable AUTOMOC 
again, then I get a compilation error when Q_OBJECT is encountered. If I do 
enable it, then CMake generates a new moc_myClass.cpp file and, since it can't 
see the place where it was included in myClass.cpp, it goes ahead and 
recompiles it, placing the object code alongside the application's other object 
code.

Now, when the application links in the static library, it finds two definitions 
of moc_myClass.cpp's object code, and gives a multiple definition error.

All the ways I've come up with so far to work around this are so hacky that I'm 
embarrassed to mention them. There must be a proper way to handle this 
situation. Please can someone advise me what it is?

(N.B. I've been doing this for years with dynamic libraries are never 
encountered a problem, presumably because there the application doesn't get to 
see the inner workings of the library's object code. This issue does seem to be 
specific to static libraries, of which I have little prior experience).


-- 

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.15.3-1043-g19bcdca

[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  19bcdca93c3a05db12652677f8d0e310797bb375 (commit)
   via  0b8c0b26ce076952bfdc0392d2c93c3597974c9f (commit)
   via  bacb50afa9ed7806a8900ab7524f2f4a4cd7d669 (commit)
   via  a81e9a0ced25490d1384316834dff36a55d4e864 (commit)
   via  573cd4e4b43d8d3b75f6e7c420b5f833cdd2120e (commit)
   via  95f23ea5d5a07da503f8e2ab9c52c82086cdcae4 (commit)
   via  706400d417e6435a442af2626a8430016e24aa9d (commit)
   via  7f8699026211c6a3055e767125021a91da4b1393 (commit)
   via  56bfb8de5d1ddc3a499b03be8ae75c9832b6f878 (commit)
   via  83b3f76a3b13ffe2d8bdf3f67c20e36e22a6955f (commit)
   via  b85407ae76951649907e8e5675fe17d65dfd5457 (commit)
   via  d55319c01d5482ff31166750717252e1b49f1e69 (commit)
   via  fb5affe0859ae1bc07d059fc11cee3daca4d8780 (commit)
   via  242d876d7b919fe6efb3a347dfa35a66e3ef58df (commit)
   via  06a2e764f0f088a212e20b85e364b5621ef639fe (commit)
   via  b46970cfe9e0c96a9794acb49fc580565bcd6e91 (commit)
   via  0b95c64e43e5f60ee9c60570f359a40e4e882096 (commit)
   via  e4c67981aca4fd736fd7503d9d105a0a6fb43828 (commit)
   via  36b939db682a9405790bee76f95673eeaeb445b8 (commit)
   via  28cf1271ed6051af46ff68f52a8c9c0435ca1234 (commit)
   via  41b0d60f48c3d8d882ec25b56d638b392121fcc8 (commit)
   via  f717e1fccf2968ffeba36dc84e428abd4f8db5c0 (commit)
   via  f0ecb123981c6b383a55f7d75e023cf4310f2074 (commit)
   via  482d858500a42a63c97d3dc11ae74d81a10bab3f (commit)
   via  f6574c9a816ffda7d9ff8c3f2e4ce0485cf28894 (commit)
   via  2edb0b71edd36031f2fcc0b65633c1c16f8e9268 (commit)
   via  62d59323899330197e795872c13c1d300a97d088 (commit)
   via  d69457077d021b7d4ea10bf2201da61222966c92 (commit)
  from  729c928c7b59919a9d379891973bda22665c75da (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=19bcdca93c3a05db12652677f8d0e310797bb375
commit 19bcdca93c3a05db12652677f8d0e310797bb375
Merge: 0b8c0b2 482d858
Author: Brad King 
AuthorDate: Fri Sep 13 13:56:02 2019 +
Commit: Kitware Robot 
CommitDate: Fri Sep 13 09:56:20 2019 -0400

Merge topic 'target-level-dependencies-via-byproducts'

482d858500 Depend: Add test for target-level dependencies via byproducts
f6574c9a81 Depend: Hook up automatic target-level dependencies via 
byproducts
2edb0b71ed cmMakefile: Add lookup from source name to targets via byproducts
62d5932389 Refatoring: Extract AnyOutputMatches utility

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0b8c0b26ce076952bfdc0392d2c93c3597974c9f
commit 0b8c0b26ce076952bfdc0392d2c93c3597974c9f
Merge: bacb50a d694570
Author: Brad King 
AuthorDate: Fri Sep 13 13:53:16 2019 +
Commit: Kitware Robot 
CommitDate: Fri Sep 13 09:53:41 2019 -0400

Merge topic 'cpack-wix-start-menu'

d69457077d CPackWIX: Allow omitting program menu folder and uninstall 
shortcut

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bacb50afa9ed7806a8900ab7524f2f4a4cd7d669
commit bacb50afa9ed7806a8900ab7524f2f4a4cd7d669
Merge: 729c928 a81e9a0
Author: Brad King 
AuthorDate: Fri Sep 13 13:52:23 2019 +
Commit: Kitware Robot 
CommitDate: Fri Sep 13 09:52:34 2019 -0400

Merge topic 'free-free-set-them-free'

a81e9a0ced cmSubdirCommand: Port away from cmCommand
573cd4e4b4 cmSetTestsPropertiesCommand: Port away from cmCommand
95f23ea5d5 cmSetSourceFilesPropertiesCommand: Port away from cmCommand
706400d417 cmRemoveDefinitionsCommand: Port away from cmCommand
7f86990262 cmQTWrapUICommand: Port away from cmCommand
56bfb8de5d cmQTWrapCPPCommand: Port away from cmCommand
83b3f76a3b cmLinkLibrariesCommand: Port away from cmCommand
b85407ae76 cmInstallTargetsCommand: Port away from cmCommand
...

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a81e9a0ced25490d1384316834dff36a55d4e864
commit a81e9a0ced25490d1384316834dff36a55d4e864
Author: Regina Pfeifer 
AuthorDate: Thu Sep 12 16:29:52 2019 +0200
Commit: Regina Pfeifer 
CommitDate: Thu Sep 12 18:16:17 2019 +0200

cmSubdirCommand: Port away from cmCommand

Ref: #19499

diff --git a/Source/cmCommands.cxx b/Source/cmCommands.cxx
index 9fb07f2..38fcf5b 100644
--- a/Source/cmCommands.cxx
+++ b/Source/cmCommands.cxx
@@ -247,7 +247,7 @@ void GetProjectCommands(cmState* state)
cm::make_unique());
   

Re: [CMake] set_target_properties ( INTERFACE_INCLUDE_DIRECTORIES ...)

[Petr Kmoch]

For completeness, there is also OPTION C:

  set_property(TARGET target PROPERTY INTERFACE_INCLUDE_DIRECTORIES
directory1 directory2)

set_target_properties() is a shorthand for setting several properties at
once, so it assumes its arguments are prop value prop value. If you need
finer control, such as appending or easy way to pass multiple values, use
the full power of set_property().

Petr

On Fri, 13 Sep 2019 at 06:24, Theodore Hall  wrote:

> On Thu, Sep 12, 2019 at 6:31 PM Craig Scott 
> wrote:
>
> OPTION A: Put quotes around a semi-colon separated string if using
>> set_target_properties():
>>
>
> Many thanks.  I had tried quotes, and I had tried a semi-colon, and I
> thought that I had tried them together, but evidently I missed that
> permutation.
>
> I'm actually sticking with OPTION B anyway -- it seems cleaner.  But I was
> mystified looking for OPTION A.
>
> --
>
> Ted Hall
>
> --
>
> 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

Re: [CMake] set_target_properties ( INTERFACE_INCLUDE_DIRECTORIES ...)

[Theodore Hall]

On Thu, Sep 12, 2019 at 6:31 PM Craig Scott  wrote:

OPTION A: Put quotes around a semi-colon separated string if using
> set_target_properties():
>

Many thanks.  I had tried quotes, and I had tried a semi-colon, and I
thought that I had tried them together, but evidently I missed that
permutation.

I'm actually sticking with OPTION B anyway -- it seems cleaner.  But I was
mystified looking for OPTION A.

-- 

Ted Hall
-- 

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.15.3-1015-g729c928

[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  729c928c7b59919a9d379891973bda22665c75da (commit)
  from  9602bcfc62d50d7bb302b02ae3b1f9afe941bae7 (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=729c928c7b59919a9d379891973bda22665c75da
commit 729c928c7b59919a9d379891973bda22665c75da
Author: Kitware Robot 
AuthorDate: Fri Sep 13 00:01:11 2019 -0400
Commit: Kitware Robot 
CommitDate: Fri Sep 13 00:01:11 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index fc86b56..e9cca30 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 15)
-set(CMake_VERSION_PATCH 20190912)
+set(CMake_VERSION_PATCH 20190913)
 #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

Re: [CMake] set_target_properties ( INTERFACE_INCLUDE_DIRECTORIES ...)

[Craig Scott]

On Fri, Sep 13, 2019 at 8:24 AM Theodore Hall  wrote:

> Greetings,
>
>   set_target_properties(target PROPERTIES
> IMPORTED_LOCATION location
> IMPORTED_IMPLIB implib
> INTERFACE_INCLUDE_DIRECTORIES directory+
>   )
>
> Is there a way to assign more than one directory to
> INTERFACE_INCLUDE_DIRECTORIES ?  The property name is plural, but every
> attempt I've made to specify more than one directory has failed.  CMake
> complains that either: I've passed the wrong number of arguments; or
> concatenates all of them into one path which of course doesn't exist.
>

> I've found a work-around using
>
>   target_include_directories (target
> INTERFACE directory1
> INTERFACE directory2
>   )
>
> It just seems odd that a property with a plural name accepts only a
> singular value.  I feel like I'm missing something.  I've tried wrapping
> multiple directories in various kinds of brackets and quotes and separating
> them with ; or , instead of whitespace.  (This is Windows, so : isn't a
> path separator; the system PATH variable uses ; as the separator.)
>


OPTION A: Put quotes around a semi-colon separated string if using
set_target_properties():

set_target_properties(target PROPERTIES
IMPORTED_LOCATION location
IMPORTED_IMPLIB implib
INTERFACE_INCLUDE_DIRECTORIES "directory1;directory2"
  )

OPTION B: List multiple directories after just one INTERFACE keyword if
using target_include_directories():

  target_include_directories (target
INTERFACE directory1 directory2
  )

Either option should work for all platforms, but note that option A will
overwrite any previous contents of INTERFACE_INCLUDED_DIRECTORIES whereas
option B will append to any previous contents. For that reason, I'd
generally recommend option B.

>
-- 
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 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] set_target_properties ( INTERFACE_INCLUDE_DIRECTORIES ...)

[Theodore Hall]

Greetings,

  set_target_properties(target PROPERTIES
IMPORTED_LOCATION location
IMPORTED_IMPLIB implib
INTERFACE_INCLUDE_DIRECTORIES directory+
  )

Is there a way to assign more than one directory to
INTERFACE_INCLUDE_DIRECTORIES ?  The property name is plural, but every
attempt I've made to specify more than one directory has failed.  CMake
complains that either: I've passed the wrong number of arguments; or
concatenates all of them into one path which of course doesn't exist.

I've found a work-around using

  target_include_directories (target
INTERFACE directory1
INTERFACE directory2
  )

It just seems odd that a property with a plural name accepts only a
singular value.  I feel like I'm missing something.  I've tried wrapping
multiple directories in various kinds of brackets and quotes and separating
them with ; or , instead of whitespace.  (This is Windows, so : isn't a
path separator; the system PATH variable uses ; as the separator.)

Thanks for any enlightenment.

-- 

Ted Hall
-- 

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] compile_commands.json question

[15 knots]

Hi all,

this is more a question to the cmake developers.

Older versions (3.15.0) of cmake produced short file names w/o spaces
on windows, when the path of the compiler executable contained spaces.
Now I have an issue [1] where compiler executable path contains spaces
with cmake 3.15.2.
Can anyone confirm whether the spaces are caused by changes made to
cmake after version 3.15.0?
Or could a user-supplied toolchain file cause the spaces?

Kind regards,
 Martin



[1] https://github.com/15knots/cmake4eclipse/issues/119#issuecomment-528716815
-- 

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] Setting RPATH lookup on macOS

[Juan Sanchez]

I never suggested copying files into the build tree.  The original
question was about how to locate libraries at runtime.  You don't
necessarily have to use @rpath, @executable_path is also a valid
option.  Another valid option one is to strip out @rpath and use
DYLD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH.

If you want to set an rpath from cmake, you can also use target properties like:
INSTALL_RPATH
BUILD_WITH_INSTALL_RPATH

where BUILD_WITH_INSTALL_RPATH is useful if you don't want to use
CMake's install system.

Regards,

Juan

On Thu, Sep 12, 2019 at 10:56 AM Michael Jackson
 wrote:
>
> On macOS you really should _not_ have to copy the libraries into the build 
> tree. I have never had to do that in 10 years of our product (Windows is a 
> different story). The trick is setting the correct options to add in the 
> paths to the libraries into the RPATH of the executable/library. (at least on 
> macOS & Linux systems).
>
>
>
> --
>
> Mike Jackson
>
>
>
>
>
> From: Juan Sanchez 
> Date: Thursday, September 12, 2019 at 11:35 AM
> To: Michael Jackson 
> Cc: CMake 
> Subject: Re: [CMake] Setting RPATH lookup on macOS
>
>
>
> The macOS install_name_tool can be used to change the RPATH of your binaries. 
>  It can also be used to set the path for each of the libraries to be loaded.  
> For a python module I compile, I copy each of its dylib into the appropriate 
> directory relative to my shared library.  I then use the install_name_tool to 
> change from an absolute path to a path relative to @loader_path.
>
>
>
> install_name_tool -change $j "@loader_path/../gcc/`basename $j`" $i
>
> where $j is the full path output from "otool -L" and "@loader_path/../gcc" 
> would point to a directory "gcc" relative to the directory containing my 
> python module.
>
> For a binary executable, I would explore placing required dylib files into a 
> directory relative to @executable_path.
>
> Regards,
>
>
>
> Juan
>
>
>
> On Wed, Sep 11, 2019 at 4:33 PM Michael Jackson  
> wrote:
>
> Already looked on google and at the CMake documentation but everything listed 
> does not seem to work so here is the setup.
>
> I am using MKL and I have a home grown FindMKL since there isn’t an official 
> one. Inside that is the typical find_library() calls which will find the 
> libraries just fine. One of those libraries is a dynamic library (.dylib). 
> Using otool -L on that library the install_name is encoded as @rpath.
>
> Now I have my add_executable(foo…) and target_link_libraries (Foo 
> ${MKL_LIBRARIES} ).
>
> Everything compiles and links fine. The issue is at runtime. The app will not 
> launch because libmkl_rt.dylib is not loaded because the path to that library 
> is not encoded into the executable.
>
> 639:[mjackson@ferb:ifort-release]$ otool -l 
> Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
>  name @rpath/libEbsdLib.dylib (offset 24)
>  name @rpath/libmkl_rt.dylib (offset 24)
>  name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset 24)
>  name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset 24)
>  name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent (offset 
> 24)
>  name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset 24)
>  name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
>  name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
>  path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib (offset 
> 12)
>  path /Users/Shared/EMsoft_SDK-ifort/Qt5.12.3/5.12.3/clang_64/lib 
> (offset 12)
>
>
> Oddly the Qt libraries and one of my own libraries do get their rpaths 
> encoded. I feel like I need to append to the RPATH that gets encoded into the 
> executable but I am not really figuring out how to do that.
>
> Help
>
> --
> Michael Jackson | Owner, President
>   BlueQuartz Software
> [e] mike.jack...@bluequartz.net
> [w] www.bluequartz.net 
>
>
> --
>
> 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 

Re: [CMake] Setting RPATH lookup on macOS

[Michael Jackson]

On macOS you really should _not_ have to copy the libraries into the build 
tree. I have never had to do that in 10 years of our product (Windows is a 
different story). The trick is setting the correct options to add in the paths 
to the libraries into the RPATH of the executable/library. (at least on macOS & 
Linux systems).

 

--

Mike Jackson

 

 

From: Juan Sanchez 
Date: Thursday, September 12, 2019 at 11:35 AM
To: Michael Jackson 
Cc: CMake 
Subject: Re: [CMake] Setting RPATH lookup on macOS

 

The macOS install_name_tool can be used to change the RPATH of your binaries.  
It can also be used to set the path for each of the libraries to be loaded.  
For a python module I compile, I copy each of its dylib into the appropriate 
directory relative to my shared library.  I then use the install_name_tool to 
change from an absolute path to a path relative to @loader_path.

 

install_name_tool -change $j "@loader_path/../gcc/`basename $j`" $i
where $j is the full path output from "otool -L" and "@loader_path/../gcc" 
would point to a directory "gcc" relative to the directory containing my python 
module.

For a binary executable, I would explore placing required dylib files into a 
directory relative to @executable_path.

Regards,

 

Juan


 

On Wed, Sep 11, 2019 at 4:33 PM Michael Jackson  
wrote:

Already looked on google and at the CMake documentation but everything listed 
does not seem to work so here is the setup.

I am using MKL and I have a home grown FindMKL since there isn’t an official 
one. Inside that is the typical find_library() calls which will find the 
libraries just fine. One of those libraries is a dynamic library (.dylib). 
Using otool -L on that library the install_name is encoded as @rpath. 

Now I have my add_executable(foo…) and target_link_libraries (Foo 
${MKL_LIBRARIES} ).

Everything compiles and links fine. The issue is at runtime. The app will not 
launch because libmkl_rt.dylib is not loaded because the path to that library 
is not encoded into the executable.

639:[mjackson@ferb:ifort-release]$ otool -l 
Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
 name @rpath/libEbsdLib.dylib (offset 24)
 name @rpath/libmkl_rt.dylib (offset 24)
 name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset 24)
 name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset 24)
 name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent (offset 24)
 name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset 24)
 name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
 name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
 path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib (offset 12)
 path /Users/Shared/EMsoft_SDK-ifort/Qt5.12.3/5.12.3/clang_64/lib 
(offset 12)


Oddly the Qt libraries and one of my own libraries do get their rpaths encoded. 
I feel like I need to append to the RPATH that gets encoded into the executable 
but I am not really figuring out how to do that.

Help

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net 


-- 

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

Re: [CMake] Setting RPATH lookup on macOS

[Juan Sanchez]

The macOS install_name_tool can be used to change the RPATH of your
binaries.  It can also be used to set the path for each of the libraries to
be loaded.  For a python module I compile, I copy each of its dylib into
the appropriate directory relative to my shared library.  I then use the
install_name_tool to change from an absolute path to a path relative to
@loader_path.

install_name_tool -change $j "@loader_path/../gcc/`basename $j`" $i
where $j is the full path output from "otool -L" and "@loader_path/../gcc"
would point to a directory "gcc" relative to the directory containing my
python module.

For a binary executable, I would explore placing required dylib files into
a directory relative to @executable_path.

Regards,

Juan



On Wed, Sep 11, 2019 at 4:33 PM Michael Jackson 
wrote:

> Already looked on google and at the CMake documentation but everything
> listed does not seem to work so here is the setup.
>
> I am using MKL and I have a home grown FindMKL since there isn’t an
> official one. Inside that is the typical find_library() calls which will
> find the libraries just fine. One of those libraries is a dynamic library
> (.dylib). Using otool -L on that library the install_name is encoded as
> @rpath.
>
> Now I have my add_executable(foo…) and target_link_libraries (Foo
> ${MKL_LIBRARIES} ).
>
> Everything compiles and links fine. The issue is at runtime. The app will
> not launch because libmkl_rt.dylib is not loaded because the path to that
> library is not encoded into the executable.
>
> 639:[mjackson@ferb:ifort-release]$ otool -l
> Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
>  name @rpath/libEbsdLib.dylib (offset 24)
>  name @rpath/libmkl_rt.dylib (offset 24)
>  name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset 24)
>  name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset 24)
>  name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent
> (offset 24)
>  name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset 24)
>  name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
>  name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
>  path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib
> (offset 12)
>  path /Users/Shared/EMsoft_SDK-ifort/Qt5.12.3/5.12.3/clang_64/lib
> (offset 12)
>
>
> Oddly the Qt libraries and one of my own libraries do get their rpaths
> encoded. I feel like I need to append to the RPATH that gets encoded into
> the executable but I am not really figuring out how to do that.
>
> Help
>
> --
> Michael Jackson | Owner, President
>   BlueQuartz Software
> [e] mike.jack...@bluequartz.net
> [w] www.bluequartz.net 
>
>
> --
>
> 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

[Cmake-commits] CMake branch, master, updated. v3.15.3-1014-g9602bcf

[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  9602bcfc62d50d7bb302b02ae3b1f9afe941bae7 (commit)
   via  1a1508c8b840ae016dc8db9da6be4cbe59d5f1aa (commit)
   via  d83bff86409c0e414046d2aeb75946037e0d2de3 (commit)
   via  a3cfb66543d307e644e4df207f2e1305200ced02 (commit)
   via  d25a5a7ec91bfa072d3cf1a302830a54506c88c0 (commit)
   via  8a18bb7cdf2478d68e11a5e532b5134ea92b3678 (commit)
  from  5bdff304847995f474797b757fe7a2755de0c1fb (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=9602bcfc62d50d7bb302b02ae3b1f9afe941bae7
commit 9602bcfc62d50d7bb302b02ae3b1f9afe941bae7
Merge: 1a1508c a3cfb66
Author: Brad King 
AuthorDate: Thu Sep 12 13:15:31 2019 +
Commit: Kitware Robot 
CommitDate: Thu Sep 12 09:16:56 2019 -0400

Merge topic 'compile-msvc-permissive-off'

a3cfb66543 Add compatibility with the cl.exe /permissive- compiler option

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1a1508c8b840ae016dc8db9da6be4cbe59d5f1aa
commit 1a1508c8b840ae016dc8db9da6be4cbe59d5f1aa
Merge: d83bff8 d25a5a7
Author: Brad King 
AuthorDate: Thu Sep 12 13:15:09 2019 +
Commit: Kitware Robot 
CommitDate: Thu Sep 12 09:15:38 2019 -0400

Merge topic 'modernize-use-auto'

d25a5a7ec9 clang-tidy: modernize-use-auto

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d83bff86409c0e414046d2aeb75946037e0d2de3
commit d83bff86409c0e414046d2aeb75946037e0d2de3
Merge: 5bdff30 8a18bb7
Author: Brad King 
AuthorDate: Thu Sep 12 13:14:38 2019 +
Commit: Kitware Robot 
CommitDate: Thu Sep 12 09:14:48 2019 -0400

Merge topic 'free-find-commands'

8a18bb7cdf cmFind*: Port away from cmCommand

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3cfb66543d307e644e4df207f2e1305200ced02
commit a3cfb66543d307e644e4df207f2e1305200ced02
Author: Alexej Harm 
AuthorDate: Wed Sep 11 15:26:20 2019 +0200
Commit: Alexej Harm 
CommitDate: Wed Sep 11 15:26:20 2019 +0200

Add compatibility with the cl.exe /permissive- compiler option

diff --git a/Source/cmUVStreambuf.h b/Source/cmUVStreambuf.h
index 873352b..0737629 100644
--- a/Source/cmUVStreambuf.h
+++ b/Source/cmUVStreambuf.h
@@ -61,7 +61,7 @@ public:
   cmBasicUVStreambuf* close();
 
 protected:
-  typename cmBasicUVStreambuf::int_type underflow() override;
+  typename cmBasicUVStreambuf::int_type underflow() override;
   std::streamsize showmanyc() override;
 
   // FIXME: Add write support
diff --git a/Utilities/Release/WiX/CustomAction/detect_nsis_overwrite.cpp 
b/Utilities/Release/WiX/CustomAction/detect_nsis_overwrite.cpp
index 4b17875..593822a 100644
--- a/Utilities/Release/WiX/CustomAction/detect_nsis_overwrite.cpp
+++ b/Utilities/Release/WiX/CustomAction/detect_nsis_overwrite.cpp
@@ -10,7 +10,8 @@ std::wstring get_property(MSIHANDLE msi_handle, std::wstring 
const& name)
 {
   DWORD size = 0;
 
-  UINT status = MsiGetPropertyW(msi_handle, name.c_str(), L"", );
+  WCHAR value_buffer[] = L"";
+  UINT status = MsiGetPropertyW(msi_handle, name.c_str(), value_buffer, );
 
   if (status == ERROR_MORE_DATA) {
 std::vector buffer(size + 1);

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d25a5a7ec91bfa072d3cf1a302830a54506c88c0
commit d25a5a7ec91bfa072d3cf1a302830a54506c88c0
Author: Regina Pfeifer 
AuthorDate: Wed Sep 4 22:17:22 2019 +0200
Commit: Regina Pfeifer 
CommitDate: Tue Sep 10 22:21:41 2019 +0200

clang-tidy: modernize-use-auto

Set the MinTypeNameLength option to an impossibly high value in order
to limit the diagnostics to iterators.  Leave new expressions and cast
expressions for later.

diff --git a/.clang-tidy b/.clang-tidy
index a6378e0..a240e9c 100644
--- a/.clang-tidy
+++ b/.clang-tidy
@@ -12,7 +12,6 @@ misc-*,\
 modernize-*,\
 -modernize-avoid-c-arrays,\
 -modernize-deprecated-headers,\
--modernize-use-auto,\
 -modernize-use-nodiscard,\
 -modernize-use-noexcept,\
 -modernize-use-transparent-functors,\
@@ -33,4 +32,6 @@ CheckOptions:
 value: '1'
   - key:   modernize-use-equals-default.IgnoreMacros
 value: '0'
+  - key:   modernize-use-auto.MinTypeNameLength
+value: '80'
 ...
diff --git a/Source/CPack/IFW/cmCPackIFWGenerator.cxx 
b/Source/CPack/IFW/cmCPackIFWGenerator.cxx
index d1ffcef..94530c1 100644
--- a/Source/CPack/IFW/cmCPackIFWGenerator.cxx
+++ b/Source/CPack/IFW/cmCPackIFWGenerator.cxx
@@ -77,8 +77,7 @@ int cmCPackIFWGenerator::PackageFiles()
 
 if 

Re: [CMake] Packaging a directory with CPack RPM

[Eric Noulard]

Le jeu. 12 sept. 2019 à 02:27, Ashish Sadanandan <
ashish.sadanan...@gmail.com> a écrit :

> Hello,
> I'm using CPack to create RPMs for an application. I have this working but
> the CPack step is quite slow. While investigating this, I noticed that all
> files in a directory I'm packaging, which contains a large number of small
> files, is being listed in the spec file.
>
> For instance, say I have
>
> set(CPACK_PACKAGING_INSTALL_PREFIX /opt/myapp)
> install(DIRECTORY ${CMAKE_BINARY_DIR}/myapp/foo
> DESTINATION foo
> COMPONENT myapp
> )
>
> In the %files section I see
>
> %files
> %dir /opt/myapp/foo
> " /opt/myapp/foo/file1"
> " /opt/myapp/foo/file2"
> ...
> " /opt/myapp/foo/file6"
>
> If I were writing the spec file by hand, this entire section could be
> replaced by a single line
>
> %files
> /opt/myapp/foo
>

CPack has no idea that the list of files are coming from an installed
*directory*, because CPack is not doing the install CMake is.
Thus CPackRPM and other CPack generators collect all installed bits inside
a given [temporary] prefix directory.

Now may be you can tell CPack to ignore some of you installed
files/directory by using: CPACK_RPM_USER_FILELIST

https://cmake.org/cmake/help/v3.15/cpack_gen/rpm.html#cpack_gen:CPack%20RPM%20Generator



> RPM will package all files within the directory if you specify the
> directory under %files (
> http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html - the
> "The %dir Directive" section)
> Is there an option to list just the directory instead of recursively
> listing all contained files within the directory?
>

AFAIK, No there is not.


I'm not claiming this is the reason for CPack being slow, I came across
> this while investigating performance and if nothing else, this will result
> in a cleaner looking spec file.
>

For performance sake you can
try CPACK_RPM_USER_BINARY_SPECFILE,
CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE
and handcraft your "user" spec file in order to see if it helps the
packaging performance.
and/or you can set CPACK_RPM_PACKAGE_DEBUG to 1 in order to get more timed
traces of CPackRPM execution.


-- 
Eric
-- 

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] can not import target external lib before being build

[Stéphane Ancelot]

Hi,

I am using this cmake snippet in order to build an external library


# -- QGLViewer --
set(QGLVIEWER_FILES 
${CMAKE_BINARY_DIR}/libQGLViewer-2.7.1/QGLViewer/qglviewer.h)


get_target_property (QT_QMAKE_EXECUTABLE Qt5::qmake IMPORTED_LOCATION)

add_custom_command(OUTPUT ${QGLVIEWER_FILES}
  COMMAND  tar xzf 
"${CMAKE_CURRENT_SOURCE_DIR}/libQGLViewer-2.7.1.tar.gz" --strip 1

  COMMAND ${QT_QMAKE_EXECUTABLE} -o QMakefile
  COMMAND make -f QMakefile
#  COMMAND ${CMAKE_COMMAND} -E touch ${LIBFOO_TAR_HEADERS}
  WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/libQGLViewer-2.7.1"
  DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/libQGLViewer-2.7.1.tar.gz"
  COMMENT "Unpacking libQGLViewer-2.7.1.tar.gz"
  VERBATIM
)

add_custom_target(qglviewer_untar DEPENDS ${QGLVIEWER_FILES})

add_library(qglviewer SHARED IMPORTED)
add_dependencies(qglviewer qglviewer_untar)

# link qglviewer
set_target_properties(qglviewer PROPERTIES
  IMPORTED_LOCATION 
"${CMAKE_CURRENT_BINARY_DIR}/libQGLViewer-2.7.1/QGLViewer/libQGLViewer-qt5.so"
  INTERFACE_INCLUDE_DIRECTORIES 
"${CMAKE_CURRENT_BINARY_DIR}/libQGLViewer-2.7.1")



Unfortunately, cmake replies with the next error when configuring :


CMake Error in API_COLLISION/CMakeLists.txt:
  Imported target "qglviewer" includes non-existent path

"/tmp/OK/BASE_SILFAX_SAFETY/build/API_COLLISION/libQGLViewer-2.7.1"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.



CMake Error in API_COLLISION/CMakeLists.txt:
  Imported target "qglviewer" includes non-existent path

"/tmp/OK/BASE_SILFAX_SAFETY/build/API_COLLISION/libQGLViewer-2.7.1"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.




-- 

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.15.3-1008-g5bdff30

[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  5bdff304847995f474797b757fe7a2755de0c1fb (commit)
  from  b5b10c8e955abb2b0f18c3e41b7892471857bcc1 (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=5bdff304847995f474797b757fe7a2755de0c1fb
commit 5bdff304847995f474797b757fe7a2755de0c1fb
Author: Kitware Robot 
AuthorDate: Thu Sep 12 00:01:06 2019 -0400
Commit: Kitware Robot 
CommitDate: Thu Sep 12 00:01:06 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 0d48a72..fc86b56 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 15)
-set(CMake_VERSION_PATCH 20190911)
+set(CMake_VERSION_PATCH 20190912)
 #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] Packaging a directory with CPack RPM

[Ashish Sadanandan]

Hello,
I'm using CPack to create RPMs for an application. I have this working but
the CPack step is quite slow. While investigating this, I noticed that all
files in a directory I'm packaging, which contains a large number of small
files, is being listed in the spec file.

For instance, say I have

set(CPACK_PACKAGING_INSTALL_PREFIX /opt/myapp)
install(DIRECTORY ${CMAKE_BINARY_DIR}/myapp/foo
DESTINATION foo
COMPONENT myapp
)

In the %files section I see

%files
%dir /opt/myapp/foo
" /opt/myapp/foo/file1"
" /opt/myapp/foo/file2"
...
" /opt/myapp/foo/file6"

If I were writing the spec file by hand, this entire section could be
replaced by a single line

%files
/opt/myapp/foo

RPM will package all files within the directory if you specify the
directory under %files (
http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html - the
"The %dir Directive" section)

Is there an option to list just the directory instead of recursively
listing all contained files within the directory?

I'm not claiming this is the reason for CPack being slow, I came across
this while investigating performance and if nothing else, this will result
in a cleaner looking spec file.

Best regards,
Ashish.
-- 

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] Setting RPATH lookup on macOS

[Michael Jackson]

On 9/11/19, 5:42 PM, "Kyle Edwards"  wrote:

On Wed, 2019-09-11 at 17:33 -0400, Michael Jackson wrote:
> Already looked on google and at the CMake documentation but
> everything listed does not seem to work so here is the setup.
> 
> I am using MKL and I have a home grown FindMKL since there isn’t an
> official one. Inside that is the typical find_library() calls which
> will find the libraries just fine. One of those libraries is a
> dynamic library (.dylib). Using otool -L on that library the
> install_name is encoded as @rpath. 
> 
> Now I have my add_executable(foo…) and target_link_libraries (Foo
> ${MKL_LIBRARIES} ).
> 
> Everything compiles and links fine. The issue is at runtime. The app
> will not launch because libmkl_rt.dylib is not loaded because the
> path to that library is not encoded into the executable.
> 
> 639:[mjackson@ferb:ifort-release]$ otool -l
> Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
>  name @rpath/libEbsdLib.dylib (offset 24)
>  name @rpath/libmkl_rt.dylib (offset 24)
>  name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset
> 24)
>  name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset
> 24)
>  name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent
> (offset 24)
>  name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset
> 24)
>  name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
>  name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
>  path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib
> (offset 12)
>  path /Users/Shared/EMsoft_SDK-
> ifort/Qt5.12.3/5.12.3/clang_64/lib (offset 12)
> 
> 
> Oddly the Qt libraries and one of my own libraries do get their
> rpaths encoded. I feel like I need to append to the RPATH that gets
> encoded into the executable but I am not really figuring out how to
> do that.
> 
> Help

Have you looked at the BUILD_RPATH and INSTALL_RPATH properties?

https://cmake.org/cmake/help/latest/prop_tgt/BUILD_RPATH.html
https://cmake.org/cmake/help/latest/prop_tgt/INSTALL_RPATH.html

Kyle

 Missed BUILD_RPATH property. Found every other 
one THanks

--
Mike Jackson



-- 

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] Setting RPATH lookup on macOS

[Kyle Edwards via CMake]

On Wed, 2019-09-11 at 17:33 -0400, Michael Jackson wrote:
> Already looked on google and at the CMake documentation but
> everything listed does not seem to work so here is the setup.
> 
> I am using MKL and I have a home grown FindMKL since there isn’t an
> official one. Inside that is the typical find_library() calls which
> will find the libraries just fine. One of those libraries is a
> dynamic library (.dylib). Using otool -L on that library the
> install_name is encoded as @rpath. 
> 
> Now I have my add_executable(foo…) and target_link_libraries (Foo
> ${MKL_LIBRARIES} ).
> 
> Everything compiles and links fine. The issue is at runtime. The app
> will not launch because libmkl_rt.dylib is not loaded because the
> path to that library is not encoded into the executable.
> 
> 639:[mjackson@ferb:ifort-release]$ otool -l
> Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
>  name @rpath/libEbsdLib.dylib (offset 24)
>  name @rpath/libmkl_rt.dylib (offset 24)
>  name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset
> 24)
>  name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset
> 24)
>  name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent
> (offset 24)
>  name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset
> 24)
>  name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
>  name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
>  path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib
> (offset 12)
>  path /Users/Shared/EMsoft_SDK-
> ifort/Qt5.12.3/5.12.3/clang_64/lib (offset 12)
> 
> 
> Oddly the Qt libraries and one of my own libraries do get their
> rpaths encoded. I feel like I need to append to the RPATH that gets
> encoded into the executable but I am not really figuring out how to
> do that.
> 
> Help

Have you looked at the BUILD_RPATH and INSTALL_RPATH properties?

https://cmake.org/cmake/help/latest/prop_tgt/BUILD_RPATH.html
https://cmake.org/cmake/help/latest/prop_tgt/INSTALL_RPATH.html

Kyle
-- 

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] Setting RPATH lookup on macOS

[Michael Jackson]

Already looked on google and at the CMake documentation but everything listed 
does not seem to work so here is the setup.

I am using MKL and I have a home grown FindMKL since there isn’t an official 
one. Inside that is the typical find_library() calls which will find the 
libraries just fine. One of those libraries is a dynamic library (.dylib). 
Using otool -L on that library the install_name is encoded as @rpath. 

Now I have my add_executable(foo…) and target_link_libraries (Foo 
${MKL_LIBRARIES} ).

Everything compiles and links fine. The issue is at runtime. The app will not 
launch because libmkl_rt.dylib is not loaded because the path to that library 
is not encoded into the executable.

639:[mjackson@ferb:ifort-release]$ otool -l 
Bin/EMsoftWorkbench.app/Contents/MacOS/EMsoftWorkbench | grep "path"
 name @rpath/libEbsdLib.dylib (offset 24)
 name @rpath/libmkl_rt.dylib (offset 24)
 name @rpath/QtOpenGL.framework/Versions/5/QtOpenGL (offset 24)
 name @rpath/QtNetwork.framework/Versions/5/QtNetwork (offset 24)
 name @rpath/QtConcurrent.framework/Versions/5/QtConcurrent (offset 24)
 name @rpath/QtWidgets.framework/Versions/5/QtWidgets (offset 24)
 name @rpath/QtGui.framework/Versions/5/QtGui (offset 24)
 name @rpath/QtCore.framework/Versions/5/QtCore (offset 24)
 path /Users/Shared/EMsoft_SDK-ifort/EbsdLib-0.1-Release/lib (offset 12)
 path /Users/Shared/EMsoft_SDK-ifort/Qt5.12.3/5.12.3/clang_64/lib 
(offset 12)


Oddly the Qt libraries and one of my own libraries do get their rpaths encoded. 
I feel like I need to append to the RPATH that gets encoded into the executable 
but I am not really figuring out how to do that.

Help

--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net 


-- 

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] Should header files be listed for a target?

[Alexander Neundorf]

On Mittwoch, 11. September 2019 21:22:04 CEST Kyle Edwards via CMake wrote:
> On Wed, 2019-09-11 at 22:00 +0300, Avraham Shukron wrote:
> > On Wed, Sep 11, 2019 at 9:49 PM Kyle Edwards  > 
> > m> wrote:
> > > You can list them or not list them. CMake will recognize them as
> > > header
> > > files and ignore them (not attempt to compile them.) It's a matter
> > > of
> > > personal preference. CMake's own CMake script lists them, but there
> > > are
> > > plenty of projects that don't and work just fine.
> > 
> > And it far as IDE generators (Xcode, CodeBlocks etc) go - don't they
> > care about headers?
> 
> Yes, the headers are more important for IDE generators than they are
> for Make/Ninja (though, AFAIK, they still don't affect the build, just
> the files that the developer sees in the generated project in the IDE.)

it depends.
If you use e.g. the kate project generator, and your project is in svn or git, 
kate retrieves the full list of files via svn/git.
Some generators check whether there is a foo.h in the same directory if there 
is a foo.cpp listed, and add this automatically.

Alex



-- 

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] Should header files be listed for a target?

[Kyle Edwards via CMake]

On Wed, 2019-09-11 at 22:00 +0300, Avraham Shukron wrote:
> 
> 
> On Wed, Sep 11, 2019 at 9:49 PM Kyle Edwards  m> wrote:
> > You can list them or not list them. CMake will recognize them as
> > header
> > files and ignore them (not attempt to compile them.) It's a matter
> > of
> > personal preference. CMake's own CMake script lists them, but there
> > are
> > plenty of projects that don't and work just fine.
> And it far as IDE generators (Xcode, CodeBlocks etc) go - don't they
> care about headers?

Yes, the headers are more important for IDE generators than they are
for Make/Ninja (though, AFAIK, they still don't affect the build, just
the files that the developer sees in the generated project in the IDE.)

Kyle
-- 

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] Should header files be listed for a target?

[Avraham Shukron]

On Wed, Sep 11, 2019 at 9:49 PM Kyle Edwards 
wrote:

> You can list them or not list them. CMake will recognize them as header
> files and ignore them (not attempt to compile them.) It's a matter of
> personal preference. CMake's own CMake script lists them, but there are
> plenty of projects that don't and work just fine.


And it far as IDE generators (Xcode, CodeBlocks etc) go - don't they care
about headers?


> > Another question - how does cmake know to create the
> > dependency between the target and the header file, even when it is
> > not listed explicitly?
>
> It uses GCC's -MD and -MF options (and the equivalents for other
> compilers), which spits out the header dependency information.


That is awesome. Thanks!
-- 

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] Should header files be listed for a target?

[Kyle Edwards via CMake]

On Wed, 2019-09-11 at 21:40 +0300, Avraham Shukron wrote:
> Hi!
> 
> I'm pretty new to cmake and I came across a question which I could
> not find any information about in the official documentation or blog
> posts.
> 
> When adding a target through add_library / add_executable - should
> the header files of the target also be listed?
> The question also applies to target_sources I guess.
> 
> On one hand - as far as I can tell it compiles perfectly fine without
> doing so, and the implicit dependency is also recognized (e.g if the
> header changes - the target will be recompiled)
> In addition most of the online examples do not list headers.
> 
> On the other hand - it seems wrong not to list them. They ARE part of
> the target, even if they do not passed to the compiler directly.
> I can also assume that some IDEs will want to know about the
> existence of these headers and their relationship with the target.
> 
> So what is the correct answer? should header files be listed as part
> of the target?

You can list them or not list them. CMake will recognize them as header
files and ignore them (not attempt to compile them.) It's a matter of
personal preference. CMake's own CMake script lists them, but there are
plenty of projects that don't and work just fine.

> Another question - how does cmake know to create the
> dependency between the target and the header file, even when it is
> not listed explicitly?

It uses GCC's -MD and -MF options (and the equivalents for other
compilers), which spits out the header dependency information.

Kyle
-- 

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] Should header files be listed for a target?

[Avraham Shukron]

Hi!

I'm pretty new to cmake and I came across a question which I could not find
any information about in the official documentation or blog posts.

When adding a target through add_library / add_executable - should the
header files of the target also be listed?
The question also applies to target_sources I guess.

On one hand - as far as I can tell it compiles perfectly fine without doing
so, and the implicit dependency is also recognized (e.g if the header
changes - the target will be recompiled)
In addition most of the online examples do not list headers.

On the other hand - it seems wrong not to list them. They ARE part of the
target, even if they do not passed to the compiler directly.
I can also assume that some IDEs will want to know about the existence of
these headers and their relationship with the target.

So what is the correct answer? should header files be listed as part of the
target?

Another question - how does cmake know to create the dependency between the
target and the header file, even when it is not listed explicitly?
-- 

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.15.3-1007-gb5b10c8

[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  b5b10c8e955abb2b0f18c3e41b7892471857bcc1 (commit)
   via  46629d6a49d8a12378778b39bc8827ae2808f3dd (commit)
   via  30006e199bb6ac3649332b26c94ccf864e1416b1 (commit)
   via  291c83f063d310f700e3e1afa756dcdf968d0f09 (commit)
   via  8e973b8e8d6542b5dd15173884bde68a9a390949 (commit)
   via  4d5bbb7704a44e56f43585b3f811f37c5200bdd0 (commit)
   via  1f6a436bf4188007b87d2582367cde8f970d5e1f (commit)
   via  5355a60fd02417a004c6b4b6b8848ce0ff1ea9fa (commit)
   via  cd7d7362782c2a582bcfd8a86a5523cf20ee6afb (commit)
   via  a20d2c85d02842a23ef1105daa078a821172cb4e (commit)
   via  b13207910e848d3c980e4b3dc176e113a3c04bbc (commit)
   via  ca7b90dcf2fc6ef5345de162ec2532454376fe2f (commit)
   via  eac8700c7853d88f0682492ccefc70b4246ccf4a (commit)
  from  7f46e4a73a4d7aaa4029a04c532d2c99635383b9 (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=b5b10c8e955abb2b0f18c3e41b7892471857bcc1
commit b5b10c8e955abb2b0f18c3e41b7892471857bcc1
Merge: 46629d6 cd7d736
Author: Brad King 
AuthorDate: Wed Sep 11 15:39:43 2019 +
Commit: Kitware Robot 
CommitDate: Wed Sep 11 11:40:11 2019 -0400

Merge topic 'ctest-no-cmcommand'

cd7d736278 cmCTestTestHandler: Port away from cmCommand

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=46629d6a49d8a12378778b39bc8827ae2808f3dd
commit 46629d6a49d8a12378778b39bc8827ae2808f3dd
Merge: 7f46e4a 30006e1
Author: Brad King 
AuthorDate: Wed Sep 11 15:38:40 2019 +
Commit: Kitware Robot 
CommitDate: Wed Sep 11 11:38:58 2019 -0400

Merge topic 'fileapiAddMoreBacktraces'

30006e199b fileapi: add backtraces for compile/link options
291c83f063 cmLocalGenerator: Add GetTargetCompileFlags overload with 
backtraces
8e973b8e8d cmLocalGenerator: Add GetTargetFlags overload with backtraces
4d5bbb7704 cmLocalGenerator: Add GetStaticLibraryFlags overload with 
backtraces
1f6a436bf4 cmLocalGenerator: Add AddCompileOptions overload with backtraces
5355a60fd0 cmLocalGenerator: Add AppendCompileOptions overload with 
backtraces
a20d2c85d0 cmLocalGenerator: Add AppendFlags overload with backtraces
b13207910e cmLocalGenerator: Clarify AddCompileOptions filter logic
...

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=30006e199bb6ac3649332b26c94ccf864e1416b1
commit 30006e199bb6ac3649332b26c94ccf864e1416b1
Author: Justin Goshi 
AuthorDate: Tue Sep 3 10:25:44 2019 -0700
Commit: Brad King 
CommitDate: Tue Sep 10 10:45:41 2019 -0400

fileapi: add backtraces for compile/link options

diff --git a/Source/cmFileAPICodemodel.cxx b/Source/cmFileAPICodemodel.cxx
index 3ac769c..805da81 100644
--- a/Source/cmFileAPICodemodel.cxx
+++ b/Source/cmFileAPICodemodel.cxx
@@ -802,9 +802,13 @@ void Target::ProcessLanguage(std::string const& lang)
   {
 // FIXME: Add flags from end section of ExpandRuleVariable,
 // which may need to be factored out.
-std::string flags;
-lg->GetTargetCompileFlags(this->GT, this->Config, lang, flags);
-cd.Flags.emplace_back(std::move(flags), JBTIndex());
+std::vector> flags =
+  lg->GetTargetCompileFlags(this->GT, this->Config, lang);
+
+cd.Flags.reserve(flags.size());
+for (const BT& f : flags) {
+  cd.Flags.emplace_back(this->ToJBT(f));
+}
   }
   std::set> defines =
 lg->GetTargetDefines(this->GT, this->Config, lang);
@@ -1264,7 +1268,7 @@ Json::Value Target::DumpLinkCommandFragments()
   Json::Value linkFragments = Json::arrayValue;
 
   std::string linkLanguageFlags;
-  std::string linkFlags;
+  std::vector> linkFlags;
   std::string frameworkPath;
   std::string linkPath;
   std::string linkLibs;
@@ -1275,7 +1279,6 @@ Json::Value Target::DumpLinkCommandFragments()
  linkLanguageFlags, linkFlags, frameworkPath, linkPath,
  this->GT);
   linkLanguageFlags = cmTrimWhitespace(linkLanguageFlags);
-  linkFlags = cmTrimWhitespace(linkFlags);
   frameworkPath = cmTrimWhitespace(frameworkPath);
   linkPath = cmTrimWhitespace(linkPath);
   linkLibs = cmTrimWhitespace(linkLibs);
@@ -1286,8 +1289,11 @@ Json::Value Target::DumpLinkCommandFragments()
   }
 
   if (!linkFlags.empty()) {
-linkFragments.append(
-  this->DumpCommandFragment(std::move(linkFlags), "flags"));
+for (BT frag : linkFlags) {
+  frag.Value = cmTrimWhitespace(frag.Value);
+  linkFragments.append(
+

[Cmake-commits] CMake branch, master, updated. v3.15.3-994-g7f46e4a

[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  7f46e4a73a4d7aaa4029a04c532d2c99635383b9 (commit)
  from  95d4a2d05562c5f0a4113527d31dadef4d7756bd (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=7f46e4a73a4d7aaa4029a04c532d2c99635383b9
commit 7f46e4a73a4d7aaa4029a04c532d2c99635383b9
Author: Kitware Robot 
AuthorDate: Wed Sep 11 00:01:05 2019 -0400
Commit: Kitware Robot 
CommitDate: Wed Sep 11 00:01:05 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 45dd11e..0d48a72 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 15)
-set(CMake_VERSION_PATCH 20190910)
+set(CMake_VERSION_PATCH 20190911)
 #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.15.3-993-g95d4a2d

[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  95d4a2d05562c5f0a4113527d31dadef4d7756bd (commit)
   via  054d626c9cca0facb372ba740b8a797d463141a3 (commit)
   via  5b96fd5b81bde4655e471a31bf0fc579c1d10136 (commit)
   via  5eaf1e1be289245267263536f5464e40d2a677c0 (commit)
   via  75692393628d757a3dadb090179e167cd9539e2f (commit)
  from  bbf48c494ad28d1c8ac5aa6e4cecb35c2cbf1b84 (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=95d4a2d05562c5f0a4113527d31dadef4d7756bd
commit 95d4a2d05562c5f0a4113527d31dadef4d7756bd
Merge: 054d626 7569239
Author: Brad King 
AuthorDate: Tue Sep 10 14:59:21 2019 +
Commit: Kitware Robot 
CommitDate: Tue Sep 10 10:59:39 2019 -0400

Merge topic 'move-setting-GENERATE-upfront'

7569239362 cmMakefile: set GENERATED property of outputs upfront

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=054d626c9cca0facb372ba740b8a797d463141a3
commit 054d626c9cca0facb372ba740b8a797d463141a3
Merge: bbf48c4 5b96fd5
Author: Brad King 
AuthorDate: Tue Sep 10 14:58:45 2019 +
Commit: Kitware Robot 
CommitDate: Tue Sep 10 10:58:53 2019 -0400

Merge topic 'MoveIfDifferent'

5b96fd5b81 use cmSystemTools::MoveFileIfDifferent()
5eaf1e1be2 cmSystemTools: introduce MoveFileIfDifferent()

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5b96fd5b81bde4655e471a31bf0fc579c1d10136
commit 5b96fd5b81bde4655e471a31bf0fc579c1d10136
Author: Rolf Eike Beer 
AuthorDate: Mon Sep 9 10:34:08 2019 +0200
Commit: Rolf Eike Beer 
CommitDate: Mon Sep 9 10:34:08 2019 +0200

use cmSystemTools::MoveFileIfDifferent()

This is better than doing CopyFileIfDifferent() followed by RemoveFile() in
two ways:

 - it is more efficient, as it avoids disk I/O for the data, even if the
   files here are usually small
 - it is atomic, so an abort during the copy will not leave a destination 
file
   with partial data behind

diff --git a/Source/cmGeneratorTarget.cxx b/Source/cmGeneratorTarget.cxx
index b4706a3..f1c48cc 100644
--- a/Source/cmGeneratorTarget.cxx
+++ b/Source/cmGeneratorTarget.cxx
@@ -3417,8 +3417,7 @@ std::string cmGeneratorTarget::GetPchHeader(const 
std::string& config,
 file << pchEpilogue << "\n";
   }
 }
-cmSystemTools::CopyFileIfDifferent(filename_tmp, filename);
-cmSystemTools::RemoveFile(filename_tmp);
+cmSystemTools::MoveFileIfDifferent(filename_tmp, filename);
   }
   return inserted.first->second;
 }
@@ -3451,8 +3450,7 @@ std::string cmGeneratorTarget::GetPchSource(const 
std::string& config,
   cmGeneratedFileStream file(filename_tmp);
   file << "/* generated by CMake */\n";
 }
-cmSystemTools::CopyFileIfDifferent(filename_tmp, filename);
-cmSystemTools::RemoveFile(filename_tmp);
+cmSystemTools::MoveFileIfDifferent(filename_tmp, filename);
   }
   return inserted.first->second;
 }
diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index 9152e94..3d8c3fb 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -2275,8 +2275,7 @@ void cmLocalGenerator::AddUnityBuild(cmGeneratorTarget* 
target,
   }
 }
   }
-  cmSystemTools::CopyFileIfDifferent(filename_tmp, filename);
-  cmSystemTools::RemoveFile(filename_tmp);
+  cmSystemTools::MoveFileIfDifferent(filename_tmp, filename);
 
   target->AddSource(filename, true);
 
diff --git a/Source/cmUseMangledMesaCommand.cxx 
b/Source/cmUseMangledMesaCommand.cxx
index cfc00e8..1fd386b 100644
--- a/Source/cmUseMangledMesaCommand.cxx
+++ b/Source/cmUseMangledMesaCommand.cxx
@@ -98,7 +98,6 @@ void CopyAndFullPathMesaHeader(const std::string& source,
   // close the files before attempting to copy
   fin.close();
   fout.close();
-  cmSystemTools::CopyFileIfDifferent(tempOutputFile, outFile);
-  cmSystemTools::RemoveFile(tempOutputFile);
+  cmSystemTools::MoveFileIfDifferent(tempOutputFile, outFile);
 }
 }

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5eaf1e1be289245267263536f5464e40d2a677c0
commit 5eaf1e1be289245267263536f5464e40d2a677c0
Author: Rolf Eike Beer 
AuthorDate: Mon Sep 9 09:09:48 2019 +0200
Commit: Rolf Eike Beer 
CommitDate: Mon Sep 9 10:30:25 2019 +0200

cmSystemTools: introduce MoveFileIfDifferent()

diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index b7287d9..074faa5 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -855,6 +855,18 @@ bool 

[Cmake-commits] CMake branch, master, updated. v3.15.3-988-gbbf48c4

[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  bbf48c494ad28d1c8ac5aa6e4cecb35c2cbf1b84 (commit)
   via  ff5028c5318c5d404390d8114d9453fc81fa9a33 (commit)
  from  05d5c66ff853f88e6dbe43bbddd18dd8babaa427 (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=bbf48c494ad28d1c8ac5aa6e4cecb35c2cbf1b84
commit bbf48c494ad28d1c8ac5aa6e4cecb35c2cbf1b84
Merge: 05d5c66 ff5028c
Author: Brad King 
AuthorDate: Tue Sep 10 14:54:39 2019 +
Commit: Kitware Robot 
CommitDate: Tue Sep 10 10:54:55 2019 -0400

Merge topic 'windows-auto-export-incremental-build'

ff5028c531 Windows: Prevent auto exports to be regenerated on every build

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ff5028c5318c5d404390d8114d9453fc81fa9a33
commit ff5028c5318c5d404390d8114d9453fc81fa9a33
Author: Daniel Eiband 
AuthorDate: Wed Aug 28 13:57:52 2019 +0200
Commit: Daniel Eiband 
CommitDate: Mon Sep 9 15:43:15 2019 +0200

Windows: Prevent auto exports to be regenerated on every build

Check modified time stamps of input files against an existing exports file
before generating the auto exports.

Fixes: #19650

diff --git a/Help/release/dev/windows-auto-export-incremental-build.rst 
b/Help/release/dev/windows-auto-export-incremental-build.rst
new file mode 100644
index 000..3126329
--- /dev/null
+++ b/Help/release/dev/windows-auto-export-incremental-build.rst
@@ -0,0 +1,6 @@
+windows-auto-export-incremental-build
+-
+
+* On Windows, existing auto generated exports are now only updated if the
+  modified time stamp of the exports is not newer than any modified time stamp
+  of the input files.
diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx
index a79a2ff..e6dd99a 100644
--- a/Source/cmcmd.cxx
+++ b/Source/cmcmd.cxx
@@ -562,19 +562,36 @@ int cmcmd::ExecuteCMakeCommand(std::vector 
const& args)
  "objlistfile [-nm=nm-path]\n";
 return 1;
   }
-  FILE* fout = cmsys::SystemTools::Fopen(args[2].c_str(), "w+");
-  if (!fout) {
-std::cerr << "could not open output .def file: " << args[2].c_str()
-  << "\n";
-return 1;
-  }
   cmsys::ifstream fin(args[3].c_str(), std::ios::in | std::ios::binary);
   if (!fin) {
 std::cerr << "could not open object list file: " << args[3].c_str()
   << "\n";
 return 1;
   }
-  std::string file;
+  std::vector files;
+  {
+std::string file;
+cmFileTime outTime;
+bool outValid = outTime.Load(args[2]);
+while (cmSystemTools::GetLineFromStream(fin, file)) {
+  files.push_back(file);
+  if (outValid) {
+cmFileTime inTime;
+outValid = inTime.Load(file) && inTime.Older(outTime);
+  }
+}
+if (outValid) {
+  // The def file already exists and all input files are older than the
+  // existing def file.
+  return 0;
+}
+  }
+  FILE* fout = cmsys::SystemTools::Fopen(args[2].c_str(), "w+");
+  if (!fout) {
+std::cerr << "could not open output .def file: " << args[2].c_str()
+  << "\n";
+return 1;
+  }
   bindexplib deffile;
   if (args.size() >= 5) {
 auto a = args[4];
@@ -585,7 +602,7 @@ int cmcmd::ExecuteCMakeCommand(std::vector 
const& args)
   std::cerr << "unknown argument: " << a << "\n";
 }
   }
-  while (cmSystemTools::GetLineFromStream(fin, file)) {
+  for (auto const& file : files) {
 std::string const& ext = cmSystemTools::GetFilenameLastExtension(file);
 if (cmSystemTools::LowerCase(ext) == ".def") {
   if (!deffile.AddDefinitionFile(file.c_str())) {
diff --git a/Tests/RunCMake/AutoExportDll/RunCMakeTest.cmake 
b/Tests/RunCMake/AutoExportDll/RunCMakeTest.cmake
index 27a609d..6c9be4b 100644
--- a/Tests/RunCMake/AutoExportDll/RunCMakeTest.cmake
+++ b/Tests/RunCMake/AutoExportDll/RunCMakeTest.cmake
@@ -7,9 +7,13 @@ file(REMOVE_RECURSE "${RunCMake_TEST_BINARY_DIR}")
 run_cmake(AutoExport)
 unset(RunCMake_TEST_OPTIONS)
 # don't run this test on Watcom or Borland make as it is not supported
-if("${RunCMake_GENERATOR}" MATCHES "Watcom WMake|Borland Makefiles")
+if(RunCMake_GENERATOR MATCHES "Watcom WMake|Borland Makefiles")
   return()
 endif()
+if(RunCMake_GENERATOR MATCHES "Ninja|Visual Studio" AND
+   CMAKE_CXX_COMPILER_ID STREQUAL "MSVC")
+  set(EXPORTS TRUE)
+endif()
 # we build debug so the say.exe 

[Cmake-commits] CMake branch, master, updated. v3.15.3-986-g05d5c66

[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  05d5c66ff853f88e6dbe43bbddd18dd8babaa427 (commit)
   via  1c2c541b0c2e1224c00cf4648f4b7ba7f1d19ec3 (commit)
   via  b31aa0285c586298e253b5f94490bca58dcce5a2 (commit)
   via  8588cdf3a021941ad15e3b289737bc9f1ecec84a (commit)
   via  f1f57cffc73cbb518d9559308f3d36a655e5738d (commit)
   via  175d8c4bf6505eeb02bb588527f3ff7b5eb143b9 (commit)
   via  7c5ec91301f31e7caff6524ab83b5bb5c614d5d7 (commit)
   via  d63c1e4e6e8507cb1c8425d521cf61fa4adbf4a8 (commit)
   via  2528b70293724b401bc1927f90f2ef91a3f3d499 (commit)
  from  c2ead49451cdd29da50954c88d45334694026ad0 (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=05d5c66ff853f88e6dbe43bbddd18dd8babaa427
commit 05d5c66ff853f88e6dbe43bbddd18dd8babaa427
Merge: 1c2c541 d63c1e4
Author: Brad King 
AuthorDate: Tue Sep 10 14:25:40 2019 +
Commit: Kitware Robot 
CommitDate: Tue Sep 10 10:27:44 2019 -0400

Merge topic 'tidy-return-brace'

d63c1e4e6e clang-tidy: modernize-return-braced-init-list

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1c2c541b0c2e1224c00cf4648f4b7ba7f1d19ec3
commit 1c2c541b0c2e1224c00cf4648f4b7ba7f1d19ec3
Merge: b31aa02 8588cdf
Author: Brad King 
AuthorDate: Tue Sep 10 14:25:57 2019 +
Commit: Kitware Robot 
CommitDate: Tue Sep 10 10:26:55 2019 -0400

Merge topic 'clang-tidy-8-macOS'

8588cdf3a0 clang-tidy: Fix bugprone-exception-escape diagnostic in test code
f1f57cffc7 clang-tidy: Fix performance-for-range-copy diagnostic in Xcode 
generator
175d8c4bf6 clang-tidy: Resolve performance-unnecessary-value-param 
diagnostics
7c5ec91301 cmGeneratedFileStreamBase: Optimize string construction in Close

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b31aa0285c586298e253b5f94490bca58dcce5a2
commit b31aa0285c586298e253b5f94490bca58dcce5a2
Merge: c2ead49 2528b70
Author: Brad King 
AuthorDate: Tue Sep 10 14:25:27 2019 +
Commit: Kitware Robot 
CommitDate: Tue Sep 10 10:25:40 2019 -0400

Merge topic 'clang-tidy-8'

2528b70293 clang-tidy: Remove old entries from blacklist

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8588cdf3a021941ad15e3b289737bc9f1ecec84a
commit 8588cdf3a021941ad15e3b289737bc9f1ecec84a
Author: Brad King 
AuthorDate: Mon Sep 9 13:49:03 2019 -0400
Commit: Brad King 
CommitDate: Mon Sep 9 13:51:23 2019 -0400

clang-tidy: Fix bugprone-exception-escape diagnostic in test code

diff --git a/Tests/CMakeLib/testUVProcessChainHelper.cxx 
b/Tests/CMakeLib/testUVProcessChainHelper.cxx
index 263665d..a77ec90 100644
--- a/Tests/CMakeLib/testUVProcessChainHelper.cxx
+++ b/Tests/CMakeLib/testUVProcessChainHelper.cxx
@@ -44,7 +44,7 @@ int main(int argc, char** argv)
   }
   if (command == "dedup") {
 // Use a nested scope to free all resources before aborting below.
-{
+try {
   std::string input = getStdin();
   std::set seen;
   std::string output;
@@ -56,6 +56,7 @@ int main(int argc, char** argv)
   }
   std::cout << output << std::flush;
   std::cerr << "3" << std::flush;
+} catch (...) {
 }
 
 // On Windows, the exit code of abort() is different between debug and

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f1f57cffc73cbb518d9559308f3d36a655e5738d
commit f1f57cffc73cbb518d9559308f3d36a655e5738d
Author: Brad King 
AuthorDate: Mon Sep 9 13:40:08 2019 -0400
Commit: Brad King 
CommitDate: Mon Sep 9 13:51:23 2019 -0400

clang-tidy: Fix performance-for-range-copy diagnostic in Xcode generator

Fix diagnostics that appear on macOS with clang-tidy-8.

diff --git a/Source/cmGlobalXCodeGenerator.cxx 
b/Source/cmGlobalXCodeGenerator.cxx
index 502a642..3dae824 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -1254,7 +1254,7 @@ bool cmGlobalXCodeGenerator::CreateXCodeTarget(
 bundleFiles[tsFlags.MacFolder].push_back(sourceFile);
   }
 }
-for (auto keySources : bundleFiles) {
+for (auto const& keySources : bundleFiles) {
   cmXCodeObject* copyFilesBuildPhase =
 this->CreateObject(cmXCodeObject::PBXCopyFilesBuildPhase);
   copyFilesBuildPhase->SetComment("Copy files");
@@ -1302,7 +1302,7 @@ bool cmGlobalXCodeGenerator::CreateXCodeTarget(
 bundleFiles[tsFlags.MacFolder].push_back(sourceFile);
   }
 }
-for (auto keySources : 

[Cmake-commits] CMake branch, master, updated. v3.15.3-977-gc2ead49

[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  c2ead49451cdd29da50954c88d45334694026ad0 (commit)
   via  4d71bea02c5269c7648913e117d0863860139bd4 (commit)
  from  f9a014e2c810799e0c148e44a2237704fdba717d (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=c2ead49451cdd29da50954c88d45334694026ad0
commit c2ead49451cdd29da50954c88d45334694026ad0
Merge: f9a014e 4d71bea
Author: Brad King 
AuthorDate: Tue Sep 10 14:01:52 2019 +
Commit: Kitware Robot 
CommitDate: Tue Sep 10 10:02:00 2019 -0400

Merge topic 'local-var'

4d71bea02c cmLocalGenerator::AddConfigVariableFlags: optimize string 
construction

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d71bea02c5269c7648913e117d0863860139bd4
commit 4d71bea02c5269c7648913e117d0863860139bd4
Author: Rolf Eike Beer 
AuthorDate: Mon Sep 9 08:15:29 2019 +0200
Commit: Rolf Eike Beer 
CommitDate: Mon Sep 9 08:15:32 2019 +0200

cmLocalGenerator::AddConfigVariableFlags: optimize string construction

diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index 9152e94..93b26ed 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -2089,12 +2089,11 @@ void 
cmLocalGenerator::AddConfigVariableFlags(std::string& flags,
   const std::string& config)
 {
   // Add the flags from the variable itself.
-  std::string flagsVar = var;
-  this->AppendFlags(flags, this->Makefile->GetSafeDefinition(flagsVar));
+  this->AppendFlags(flags, this->Makefile->GetSafeDefinition(var));
   // Add the flags from the build-type specific variable.
   if (!config.empty()) {
-flagsVar += "_";
-flagsVar += cmSystemTools::UpperCase(config);
+const std::string flagsVar =
+  cmStrCat(var, '_', cmSystemTools::UpperCase(config));
 this->AppendFlags(flags, this->Makefile->GetSafeDefinition(flagsVar));
   }
 }

---

Summary of changes:
 Source/cmLocalGenerator.cxx | 7 +++
 1 file changed, 3 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.15.3-975-gf9a014e

[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  f9a014e2c810799e0c148e44a2237704fdba717d (commit)
  from  922482dd3acd2af9d26476134b3386c5a7695a03 (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=f9a014e2c810799e0c148e44a2237704fdba717d
commit f9a014e2c810799e0c148e44a2237704fdba717d
Author: Kitware Robot 
AuthorDate: Tue Sep 10 00:01:05 2019 -0400
Commit: Kitware Robot 
CommitDate: Tue Sep 10 00:01:05 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 857e5f1..45dd11e 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 15)
-set(CMake_VERSION_PATCH 20190909)
+set(CMake_VERSION_PATCH 20190910)
 #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

Re: [CMake] try_compile with multiple include directories

[Isuru Fernando]

Yes, semicolon worked.

Thanks Kyle and Jakub for the responses.

Isuru

On Mon, Sep 9, 2019 at 9:04 AM Kyle Edwards 
wrote:

> On Sun, 2019-09-08 at 14:07 -0500, Isuru Fernando wrote:
> > Hello,
> >
> > I can use the following to get try_compile to include one directory.
> >
> > CMAKE_FLAGS "-DINCLUDE_DIRECTORIES=dir1"
> >
> > How do you use try_compile when I have multiple directories to pass
> > to it?
> >
> > Isuru
>
> Use a semicolon:
>
> CMAKE_FLAGS "-DINCLUDE_DIRECTORIES=dir1;dir2"
>
> Kyle
>
-- 

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] try_compile with multiple include directories

[Kyle Edwards via CMake]

On Sun, 2019-09-08 at 14:07 -0500, Isuru Fernando wrote:
> Hello,
> 
> I can use the following to get try_compile to include one directory.
> 
> CMAKE_FLAGS "-DINCLUDE_DIRECTORIES=dir1"
> 
> How do you use try_compile when I have multiple directories to pass
> to it?
> 
> Isuru

Use a semicolon:

CMAKE_FLAGS "-DINCLUDE_DIRECTORIES=dir1;dir2"

Kyle
-- 

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.15.3-974-g922482d

[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  922482dd3acd2af9d26476134b3386c5a7695a03 (commit)
   via  2d7bb13da7ec13ce73facaff07847d75d8a20e91 (commit)
  from  d803d6b59f294b1bd1bd32beb75468399560be95 (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=922482dd3acd2af9d26476134b3386c5a7695a03
commit 922482dd3acd2af9d26476134b3386c5a7695a03
Merge: d803d6b 2d7bb13
Author: Brad King 
AuthorDate: Mon Sep 9 13:41:20 2019 +
Commit: Kitware Robot 
CommitDate: Mon Sep 9 09:41:32 2019 -0400

Merge topic 
'cuda_resolve_device_symbols_on_static_lib_collect_deps_properly'

2d7bb13da7 CUDA: static lib device linking computes required static libs

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2d7bb13da7ec13ce73facaff07847d75d8a20e91
commit 2d7bb13da7ec13ce73facaff07847d75d8a20e91
Author: Robert Maynard 
AuthorDate: Tue Aug 27 13:52:55 2019 -0400
Commit: Robert Maynard 
CommitDate: Thu Sep 5 10:51:02 2019 -0400

CUDA: static lib device linking computes required static libs

Previously the CMake didn't compute the required set of libraries
needed to properly device link a static library when
CUDA_RESOLVE_DEVICE_SYMBOLS was enabled.

diff --git a/Source/cmLinkLineDeviceComputer.cxx 
b/Source/cmLinkLineDeviceComputer.cxx
index 9c0e20f..1a602ca 100644
--- a/Source/cmLinkLineDeviceComputer.cxx
+++ b/Source/cmLinkLineDeviceComputer.cxx
@@ -82,6 +82,9 @@ std::string cmLinkLineDeviceComputer::ComputeLinkLibraries(
   ItemVector const& items = cli.GetItems();
   std::string config = cli.GetConfig();
   bool skipItemAfterFramework = false;
+  // Note:
+  // Any modification of this algorithm should be reflected also in
+  // cmVisualStudio10TargetGenerator::ComputeCudaLinkOptions
   for (auto const& item : items) {
 if (skipItemAfterFramework) {
   skipItemAfterFramework = false;
@@ -91,6 +94,7 @@ std::string cmLinkLineDeviceComputer::ComputeLinkLibraries(
 if (item.Target) {
   bool skip = false;
   switch (item.Target->GetType()) {
+case cmStateEnums::SHARED_LIBRARY:
 case cmStateEnums::MODULE_LIBRARY:
 case cmStateEnums::INTERFACE_LIBRARY:
   skip = true;
diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index f0145c5..ee0d4da 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -14,6 +14,7 @@
 #include "cmInstallScriptGenerator.h"
 #include "cmInstallTargetGenerator.h"
 #include "cmLinkLineComputer.h"
+#include "cmLinkLineDeviceComputer.h"
 #include "cmMakefile.h"
 #include "cmRulePlaceholderExpander.h"
 #include "cmSourceFile.h"
@@ -1152,6 +1153,12 @@ void cmLocalGenerator::GetTargetFlags(
   switch (target->GetType()) {
 case cmStateEnums::STATIC_LIBRARY:
   this->GetStaticLibraryFlags(linkFlags, buildType, linkLanguage, target);
+  if (pcli && dynamic_cast(linkLineComputer)) {
+// Compute the required cuda device link libraries when
+// resolving cuda device symbols
+this->OutputLinkLibraries(pcli, linkLineComputer, linkLibs,
+  frameworkPath, linkPath);
+  }
   break;
 case cmStateEnums::MODULE_LIBRARY:
   libraryLinkVariable = "CMAKE_MODULE_LINKER_FLAGS";
diff --git a/Source/cmMakefileLibraryTargetGenerator.cxx 
b/Source/cmMakefileLibraryTargetGenerator.cxx
index 4244402..d51bba4 100644
--- a/Source/cmMakefileLibraryTargetGenerator.cxx
+++ b/Source/cmMakefileLibraryTargetGenerator.cxx
@@ -300,19 +300,16 @@ void 
cmMakefileLibraryTargetGenerator::WriteDeviceLibraryRules(
 
 // Collect up flags to link in needed libraries.
 std::string linkLibs;
-if (this->GeneratorTarget->GetType() != cmStateEnums::STATIC_LIBRARY) {
-
-  std::unique_ptr linkLineComputer(
-new cmLinkLineDeviceComputer(
-  this->LocalGenerator,
-  this->LocalGenerator->GetStateSnapshot().GetDirectory()));
-  linkLineComputer->SetForResponse(useResponseFileForLibs);
-  linkLineComputer->SetUseWatcomQuote(useWatcomQuote);
-  linkLineComputer->SetRelink(relink);
-
-  this->CreateLinkLibs(linkLineComputer.get(), linkLibs,
-   useResponseFileForLibs, depends);
-}
+std::unique_ptr linkLineComputer(
+  new cmLinkLineDeviceComputer(
+this->LocalGenerator,
+this->LocalGenerator->GetStateSnapshot().GetDirectory()));
+linkLineComputer->SetForResponse(useResponseFileForLibs);
+linkLineComputer->SetUseWatcomQuote(useWatcomQuote);
+

[Cmake-commits] CMake branch, master, updated. v3.15.3-972-gd803d6b

[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  d803d6b59f294b1bd1bd32beb75468399560be95 (commit)
  from  c52a354244086a3ad591ae01eb506ec5851bcfc2 (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=d803d6b59f294b1bd1bd32beb75468399560be95
commit d803d6b59f294b1bd1bd32beb75468399560be95
Author: Kitware Robot 
AuthorDate: Mon Sep 9 00:01:04 2019 -0400
Commit: Kitware Robot 
CommitDate: Mon Sep 9 00:01:04 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index fd605fa..857e5f1 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 15)
-set(CMake_VERSION_PATCH 20190908)
+set(CMake_VERSION_PATCH 20190909)
 #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] try_compile with multiple include directories

[Isuru Fernando]

Hello,

I can use the following to get try_compile to include one directory.

CMAKE_FLAGS "-DINCLUDE_DIRECTORIES=dir1"

How do you use try_compile when I have multiple directories to pass to it?

Isuru
-- 

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] Specify "NO multilib" for cross compilation ???

[Pei Jia]

Hi, all:

I'm trying to cross compile a package with CMake. I strictly followed 
the documentation here: 
https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html


But, still obtained the following ERROR messages:



CMake Error at /usr/share/cmake-3.13/Modules/CMakeTestCCompiler.cmake:52 
(message):

The C compiler

"../RPi/bin/arm-rpi-linux-gnueabihf-gcc"

is not able to compile a simple test program.

It fails with the following output:

Change Dir: ../flann/build/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_78471/fast"
/usr/bin/make -f CMakeFiles/cmTC_78471.dir/build.make 
CMakeFiles/cmTC_78471.dir/build

make[1]: Entering directory '../flann/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_78471.dir/testCCompiler.c.o
../RPi/bin/arm-rpi-linux-gnueabihf-gcc --sysroot=../rootfs -o
CMakeFiles/cmTC_78471.dir/testCCompiler.c.o -c 
../flann/build/CMakeFiles/CMakeTmp/testCCompiler.c

Linking C executable cmTC_78471
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_78471.dir/link.txt 
--verbose=1

../RPi/bin/arm-rpi-linux-gnueabihf-gcc --sysroot=../rootfs -rdynamic
CMakeFiles/cmTC_78471.dir/testCCompiler.c.o -o cmTC_78471
../RPi/lib/gcc/arm-rpi-linux-gnueabihf/8.3.0/../../../../arm-rpi-linux-gnueabihf/bin/ld: 
cannot find crt1.o: No such file or directory
../RPi/lib/gcc/arm-rpi-linux-gnueabihf/8.3.0/../../../../arm-rpi-linux-gnueabihf/bin/ld: 
cannot find crti.o: No such file or directory

collect2: error: ld returned 1 exit status
make[1]: *** [CMakeFiles/cmTC_78471.dir/build.make:87: cmTC_78471] Error 1
make[1]: Leaving directory '../flann/build/CMakeFiles/CMakeTmp'
make: *** [Makefile:121: cmTC_78471/fast] Error 2




CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:24 (project)


To be more specific, I'm trying to cross compile flann 
(https://github.com/mariusmuja/flann) for raspberry pi 3B 
(https://www.raspberrypi.org/products/raspberry-pi-3-model-b/) .



Can anybody please give me a hand?


Cheers


--
Dr. Pei Jia CEO of Longer Vision Technology (Canada) Ltd.
Website: https://www.longervision.ca
Email: jia...@longervision.com 
cell phone in Canada: 778-863-5816 
-- 

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.15.3-971-gc52a354

[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  c52a354244086a3ad591ae01eb506ec5851bcfc2 (commit)
  from  9aecf2e84016568d41cd199eb8a57d370f442041 (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=c52a354244086a3ad591ae01eb506ec5851bcfc2
commit c52a354244086a3ad591ae01eb506ec5851bcfc2
Author: Kitware Robot 
AuthorDate: Sun Sep 8 00:01:20 2019 -0400
Commit: Kitware Robot 
CommitDate: Sun Sep 8 00:01:20 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 8565e4b..fd605fa 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 15)
-set(CMake_VERSION_PATCH 20190907)
+set(CMake_VERSION_PATCH 20190908)
 #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.15.3-970-g9aecf2e

[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  9aecf2e84016568d41cd199eb8a57d370f442041 (commit)
  from  ca8c3d64c8accebeacf322f0574494ffddb039c5 (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=9aecf2e84016568d41cd199eb8a57d370f442041
commit 9aecf2e84016568d41cd199eb8a57d370f442041
Author: Kitware Robot 
AuthorDate: Sat Sep 7 00:01:06 2019 -0400
Commit: Kitware Robot 
CommitDate: Sat Sep 7 00:01:06 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index b54dbd1..8565e4b 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 15)
-set(CMake_VERSION_PATCH 20190906)
+set(CMake_VERSION_PATCH 20190907)
 #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.15.3-969-gca8c3d6

[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  ca8c3d64c8accebeacf322f0574494ffddb039c5 (commit)
   via  45e90f62dd422a93b14b5ed9d49d26a51116d4fd (commit)
   via  32c9ab8a1ba1dc55275aaad4285f0006ee8d4ea0 (commit)
   via  5acf0de1feb83a8ec5d8f1348091501919b17cad (commit)
   via  0d06cc457c2b526584c52153001d88051f6b5fbd (commit)
   via  1d3f5ebb0d3da35d1b5b1287f39115b188ac5f6a (commit)
   via  a1ddf2d0ba6268e29a9456948828f59d044791f1 (commit)
  from  7772c1db03b2424d0b8bc0f7b89e5733d2770b1d (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=ca8c3d64c8accebeacf322f0574494ffddb039c5
commit ca8c3d64c8accebeacf322f0574494ffddb039c5
Merge: 45e90f6 1d3f5eb
Author: Brad King 
AuthorDate: Fri Sep 6 16:37:55 2019 +
Commit: Kitware Robot 
CommitDate: Fri Sep 6 12:38:04 2019 -0400

Merge topic 'use-using'

1d3f5ebb0d clang-tidy: Enable check modernize-use-using
a1ddf2d0ba clang-tidy: Replace typedef with using

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

diff --cc Source/CPack/cmCPackArchiveGenerator.h
index f5be0aa,760b03d..461df66
--- a/Source/CPack/cmCPackArchiveGenerator.h
+++ b/Source/CPack/cmCPackArchiveGenerator.h
@@@ -22,16 -22,8 +22,16 @@@ class cmCPackComponent
  class cmCPackArchiveGenerator : public cmCPackGenerator
  {
  public:
-   typedef cmCPackGenerator Superclass;
+   using Superclass = cmCPackGenerator;
  
 +  static cmCPackGenerator* Create7ZGenerator();
 +  static cmCPackGenerator* CreateTBZ2Generator();
 +  static cmCPackGenerator* CreateTGZGenerator();
 +  static cmCPackGenerator* CreateTXZGenerator();
 +  static cmCPackGenerator* CreateTZGenerator();
 +  static cmCPackGenerator* CreateTZSTGenerator();
 +  static cmCPackGenerator* CreateZIPGenerator();
 +
/**
 * Construct generator
 */

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=45e90f62dd422a93b14b5ed9d49d26a51116d4fd
commit 45e90f62dd422a93b14b5ed9d49d26a51116d4fd
Merge: 32c9ab8 5acf0de
Author: Brad King 
AuthorDate: Fri Sep 6 16:35:00 2019 +
Commit: Kitware Robot 
CommitDate: Fri Sep 6 12:35:49 2019 -0400

Merge topic 'simplify-AppendFlags'

5acf0de1fe cmLocalGenerator: Remove AppendFlags 'const char*' overload

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=32c9ab8a1ba1dc55275aaad4285f0006ee8d4ea0
commit 32c9ab8a1ba1dc55275aaad4285f0006ee8d4ea0
Merge: 7772c1d 0d06cc4
Author: Brad King 
AuthorDate: Fri Sep 6 16:34:46 2019 +
Commit: Kitware Robot 
CommitDate: Fri Sep 6 12:35:00 2019 -0400

Merge topic 'iwyu-freebsd-pkg'

0d06cc457c CPack/FreeBSD: Cleanup include-what-you-use diagnostics

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5acf0de1feb83a8ec5d8f1348091501919b17cad
commit 5acf0de1feb83a8ec5d8f1348091501919b17cad
Author: Brad King 
AuthorDate: Thu Sep 5 10:31:56 2019 -0400
Commit: Brad King 
CommitDate: Thu Sep 5 10:31:56 2019 -0400

cmLocalGenerator: Remove AppendFlags 'const char*' overload

Update call sites to ensure the `std::string` argument can be
constructed safely.

diff --git a/Source/cmCommonTargetGenerator.cxx 
b/Source/cmCommonTargetGenerator.cxx
index 49db505..54443f2 100644
--- a/Source/cmCommonTargetGenerator.cxx
+++ b/Source/cmCommonTargetGenerator.cxx
@@ -90,7 +90,7 @@ void cmCommonTargetGenerator::AppendFortranFormatFlags(
   }
   if (var) {
 this->LocalCommonGenerator->AppendFlags(
-  flags, this->Makefile->GetDefinition(var));
+  flags, this->Makefile->GetSafeDefinition(var));
   }
 }
 
diff --git a/Source/cmLocalCommonGenerator.cxx 
b/Source/cmLocalCommonGenerator.cxx
index 7c36bdc..f86955d 100644
--- a/Source/cmLocalCommonGenerator.cxx
+++ b/Source/cmLocalCommonGenerator.cxx
@@ -35,10 +35,8 @@ std::string cmLocalCommonGenerator::GetTargetFortranFlags(
   std::string flags;
 
   // Enable module output if necessary.
-  if (const char* modout_flag =
-this->Makefile->GetDefinition("CMAKE_Fortran_MODOUT_FLAG")) {
-this->AppendFlags(flags, modout_flag);
-  }
+  this->AppendFlags(
+flags, this->Makefile->GetSafeDefinition("CMAKE_Fortran_MODOUT_FLAG"));
 
   // Add a module output directory flag if necessary.
   std::string mod_dir =
diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index e2402ad..9152e94 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -1125,10 +1125,10 @@ void 
cmLocalGenerator::GetStaticLibraryFlags(std::string& flags,
   

[Cmake-commits] CMake branch, master, updated. v3.15.3-962-g7772c1d

[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  7772c1db03b2424d0b8bc0f7b89e5733d2770b1d (commit)
  from  a2d4968ab914d5cf02457306ec8f76177a794520 (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=7772c1db03b2424d0b8bc0f7b89e5733d2770b1d
commit 7772c1db03b2424d0b8bc0f7b89e5733d2770b1d
Author: Kitware Robot 
AuthorDate: Fri Sep 6 00:01:04 2019 -0400
Commit: Kitware Robot 
CommitDate: Fri Sep 6 00:01:04 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 545b0a9..b54dbd1 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 15)
-set(CMake_VERSION_PATCH 20190905)
+set(CMake_VERSION_PATCH 20190906)
 #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.15.3-961-ga2d4968

[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  a2d4968ab914d5cf02457306ec8f76177a794520 (commit)
   via  611eb26b9db1b0ff1e83a6983b6cdf79f2dca0d5 (commit)
  from  6db8f6a410d99e9a66847530bb520b329d2f1a9e (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=a2d4968ab914d5cf02457306ec8f76177a794520
commit a2d4968ab914d5cf02457306ec8f76177a794520
Merge: 6db8f6a 611eb26
Author: Craig Scott 
AuthorDate: Fri Sep 6 00:03:30 2019 +
Commit: Kitware Robot 
CommitDate: Thu Sep 5 20:03:55 2019 -0400

Merge topic 'doxygen-add-docs-USE_STAMP_FILE'

611eb26b9d FindDoxygen: add USE_STAMP_FILE option

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=611eb26b9db1b0ff1e83a6983b6cdf79f2dca0d5
commit 611eb26b9db1b0ff1e83a6983b6cdf79f2dca0d5
Author: Nikita Sirgienko 
AuthorDate: Tue Apr 16 14:37:45 2019 +0300
Commit: Craig Scott 
CommitDate: Fri Sep 6 09:12:09 2019 +1000

FindDoxygen: add USE_STAMP_FILE option

The new option enables the behavior of only building if sources change.

diff --git a/Help/release/dev/doxygen-add-docs-USE_STAMP_FILE.rst 
b/Help/release/dev/doxygen-add-docs-USE_STAMP_FILE.rst
new file mode 100644
index 000..700ee6c
--- /dev/null
+++ b/Help/release/dev/doxygen-add-docs-USE_STAMP_FILE.rst
@@ -0,0 +1,7 @@
+doxygen-add-docs-USE_STAMP_FILE
+---
+
+* The :command:`doxygen_add_docs` command from the :module:`FindDoxygen`
+  module gained a new ``USE_STAMP_FILE`` option.  When this option present,
+  the custom target created by the command will only re-run Doxygen if any
+  of the source files have changed since the last successful run.
diff --git a/Modules/FindDoxygen.cmake b/Modules/FindDoxygen.cmake
index ebd0b24..faa03f9 100644
--- a/Modules/FindDoxygen.cmake
+++ b/Modules/FindDoxygen.cmake
@@ -70,6 +70,7 @@ Functions
 doxygen_add_docs(targetName
 [filesOrDirs...]
 [ALL]
+[USE_STAMP_FILE]
 [WORKING_DIRECTORY dir]
 [COMMENT comment])
 
@@ -92,7 +93,19 @@ Functions
   the :command:`add_custom_target` command used to create the custom target
   internally.
 
-  If ALL is set, the target will be added to the default build target.
+  If ``ALL`` is set, the target will be added to the default build target.
+
+  If ``USE_STAMP_FILE`` is set, the custom command defined by this function 
will
+  create a stamp file with the name ``.stamp`` in the current
+  binary directory whenever doxygen is re-run.  With this option present, all
+  items in  must be files (i.e. no directories, symlinks or
+  wildcards) and each of the files must exist at the time
+  ``doxygen_add_docs()`` is called.  An error will be raised if any of the
+  items listed is missing or is not a file when ``USE_STAMP_FILE`` is given.
+  A dependency will be created on each of the files so that doxygen will only
+  be re-run if one of the files is updated.  Without the ``USE_STAMP_FILE``
+  option, doxygen will always be re-run if the  target is built
+  regardless of whether anything listed in  has changed.
 
   The contents of the generated ``Doxyfile`` can be customized by setting CMake
   variables before calling ``doxygen_add_docs()``. Any variable with a name of
@@ -801,7 +814,7 @@ function(doxygen_list_to_quoted_strings LIST_VARIABLE)
 endfunction()
 
 function(doxygen_add_docs targetName)
-set(_options ALL)
+set(_options ALL USE_STAMP_FILE)
 set(_one_value_args WORKING_DIRECTORY COMMENT)
 set(_multi_value_args)
 cmake_parse_arguments(_args
@@ -978,9 +991,10 @@ doxygen_add_docs() for target ${targetName}")
 endif()
 
 # Build up a list of files we can identify from the inputs so we can list
-# them as SOURCES in the custom target (makes them display in IDEs). We
-# must do this before we transform the various DOXYGEN_... variables below
-# because we need to process DOXYGEN_INPUT as a list first.
+# them as DEPENDS and SOURCES in the custom command/target (the latter
+# makes them display in IDEs). This must be done before we transform the
+# various DOXYGEN_... variables below because we need to process
+# DOXYGEN_INPUT as a list first.
 unset(_sources)
 foreach(_item IN LISTS DOXYGEN_INPUT)
 get_filename_component(_abs_item "${_item}" ABSOLUTE
@@ -989,11 +1003,13 @@ doxygen_add_docs() for target ${targetName}")
NOT IS_DIRECTORY "${_abs_item}" AND
NOT IS_SYMLINK "${_abs_item}")
 list(APPEND _sources "${_abs_item}")
+

[CMake] fortran end of file error in object files

[Kurt R. Sansom]

Dear all,
   I am working on some fortran code that links to c++, and have run into an 
issue where make doesn't like the generated object file. There is something 
weird going on either in the preprocessing or something weird with my machine. 
What is weird is that people with the same OS, compiler etc don't have this 
issue and it builds without a problem inside of docker on this machine. I also 
have compiled some fortran examples that have hardcoded gfortran calls and 
works fine. I tested this with a different fotran project (json fortran 
library) and the cmake gave the same error.

I tried with cmake latest release and the same problem occurs. Can someone 
point me in a better direction here. Compiling on ubuntu 18.04, gcc-7, gfortran.

~Kurt  Sansom


Errors look something like:

f951: Fatal Error: Reading module 'class_patch' at line 1368 column 66: 
Unexpected EOF
compilation terminated.
src/core/CMakeFiles/core.dir/build.make:470: recipe for target 
'src/core/CMakeFiles/core.dir/class-vars/class_geom_printer.f90.o' failed
make[2]: *** [src/core/CMakeFiles/core.dir/class-vars/class_geom_printer.f90.o] 
Error 1
CMakeFiles/Makefile2:296: recipe for target 'src/core/CMakeFiles/core.dir/all' 
failed
make[1]: *** [src/core/CMakeFiles/core.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2



-- 

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.15.3-959-g6db8f6a

[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  6db8f6a410d99e9a66847530bb520b329d2f1a9e (commit)
   via  3beb2c440badc293c7cf783abe0f1f5e9fb6f497 (commit)
  from  ac4d6d4a9d9b81773e61c643169cb2afe1bab644 (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=6db8f6a410d99e9a66847530bb520b329d2f1a9e
commit 6db8f6a410d99e9a66847530bb520b329d2f1a9e
Merge: ac4d6d4 3beb2c4
Author: Brad King 
AuthorDate: Thu Sep 5 13:07:22 2019 +
Commit: Kitware Robot 
CommitDate: Thu Sep 5 09:07:30 2019 -0400

Merge topic 'doc-remove_directory-symlink'

3beb2c440b cmake: Document -E remove_directory symlink behavior

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3beb2c440badc293c7cf783abe0f1f5e9fb6f497
commit 3beb2c440badc293c7cf783abe0f1f5e9fb6f497
Author: Brad King 
AuthorDate: Thu Sep 5 08:30:09 2019 -0400
Commit: Brad King 
CommitDate: Thu Sep 5 08:31:49 2019 -0400

cmake: Document -E remove_directory symlink behavior

Update documentation for the change made by commit e6c9a8bac3 (cmake:
Teach -E remove_directory to remove directory symlinks, 2019-08-26).
Also add a release note.

Issue: #19533

diff --git a/Help/manual/cmake.1.rst b/Help/manual/cmake.1.rst
index 0645e41..2576cde 100644
--- a/Help/manual/cmake.1.rst
+++ b/Help/manual/cmake.1.rst
@@ -536,7 +536,8 @@ Available commands are:
 
 ``remove_directory ...``
   Remove  directories and their contents.  If a directory does
-  not exist it will be silently ignored.
+  not exist it will be silently ignored.  If  is a symlink to
+  a directory, just the symlink will be removed.
 
 ``rename  ``
   Rename a file or directory (on one volume). If file with the  
name
diff --git a/Help/release/dev/remove_directory-symlink.rst 
b/Help/release/dev/remove_directory-symlink.rst
new file mode 100644
index 000..0896388
--- /dev/null
+++ b/Help/release/dev/remove_directory-symlink.rst
@@ -0,0 +1,6 @@
+remove_directory-symlink
+
+
+* The :manual:`cmake(1)` ``-E remove_directory`` command-line tool,
+  when given the path to a symlink to a directory, now removes just
+  the symlink.  It no longer removes content of the linked directory.

---

Summary of changes:
 Help/manual/cmake.1.rst   | 3 ++-
 Help/release/dev/remove_directory-symlink.rst | 6 ++
 2 files changed, 8 insertions(+), 1 deletion(-)
 create mode 100644 Help/release/dev/remove_directory-symlink.rst


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.15.3-957-gac4d6d4

[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  ac4d6d4a9d9b81773e61c643169cb2afe1bab644 (commit)
   via  7786a05c707dc5ffe9fdf7a6b468f56ed18c9e8a (commit)
   via  1353802af366bd64ba8f730e6f93d4c416107d48 (commit)
   via  8dfeb5d278625c55be1cc82399d29c0305ee4438 (commit)
   via  7114c141e27532df709fcae1266bb4ce9b6e850c (commit)
  from  fcba9c3baa00631407f493f97afe7e9cd1b844a7 (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=ac4d6d4a9d9b81773e61c643169cb2afe1bab644
commit ac4d6d4a9d9b81773e61c643169cb2afe1bab644
Merge: fcba9c3 7786a05
Author: Brad King 
AuthorDate: Thu Sep 5 12:35:29 2019 +
Commit: Kitware Robot 
CommitDate: Thu Sep 5 08:36:06 2019 -0400

Merge topic 'unity-build'

7786a05c70 Unity build: Add XCode support
1353802af3 Unity build: Add unit tests
8dfeb5d278 Unity build: Add support for Visual Studio generator
7114c141e2 Unity build: Add support for Ninja and Makefile generators

Acked-by: Kitware Robot 
Acked-by: Stanislav Ershov 
Acked-by: Evgeniy Dushistov 
Acked-by: Viktor Kirilov 
Merge-request: !3611


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7786a05c707dc5ffe9fdf7a6b468f56ed18c9e8a
commit 7786a05c707dc5ffe9fdf7a6b468f56ed18c9e8a
Author: Cristian Adam 
AuthorDate: Tue Jul 30 18:31:16 2019 +0200
Commit: Cristian Adam 
CommitDate: Fri Aug 30 20:39:37 2019 +0200

Unity build: Add XCode support

diff --git a/Source/cmGlobalXCodeGenerator.cxx 
b/Source/cmGlobalXCodeGenerator.cxx
index 427ab44..74d97e1 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -2839,6 +2839,7 @@ bool cmGlobalXCodeGenerator::CreateGroups(
 continue;
   }
 
+  generator->AddUnityBuild(gtgt, "");
   generator->AddPchDependencies(gtgt, "");
 
   auto addSourceToGroup = [this, mf, gtgt,
diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index 6249c28..c85ee2d 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -2266,7 +2266,11 @@ void cmLocalGenerator::AddUnityBuild(cmGeneratorTarget* 
target,
 for (; begin != end; ++begin) {
   cmSourceFile* sf = filtered_sources[begin];
 
-  if (!this->GetGlobalGenerator()->IsMultiConfig()) {
+  // Only in Visual Studio generator we keep the source files
+  // for explicit processing. For the rest the source files will
+  // not be included in the project.
+  if (!this->GetGlobalGenerator()->IsMultiConfig() ||
+  this->GetGlobalGenerator()->IsXcode()) {
 sf->SetProperty("HEADER_FILE_ONLY", "ON");
   }
   sf->SetProperty("UNITY_SOURCE_FILE", filename.c_str());

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1353802af366bd64ba8f730e6f93d4c416107d48
commit 1353802af366bd64ba8f730e6f93d4c416107d48
Author: Cristian Adam 
AuthorDate: Mon Jul 29 19:33:55 2019 +0200
Commit: Cristian Adam 
CommitDate: Fri Aug 30 20:39:32 2019 +0200

Unity build: Add unit tests

diff --git a/Tests/RunCMake/CMakeLists.txt b/Tests/RunCMake/CMakeLists.txt
index 48eebcc..8fd5234 100644
--- a/Tests/RunCMake/CMakeLists.txt
+++ b/Tests/RunCMake/CMakeLists.txt
@@ -576,3 +576,4 @@ endif()
 add_RunCMake_test("CTestCommandExpandLists")
 
 add_RunCMake_test(PrecompileHeaders)
+add_RunCMake_test("UnityBuild")
diff --git a/Tests/RunCMake/UnityBuild/CMakeLists.txt 
b/Tests/RunCMake/UnityBuild/CMakeLists.txt
new file mode 100644
index 000..77030d6
--- /dev/null
+++ b/Tests/RunCMake/UnityBuild/CMakeLists.txt
@@ -0,0 +1,3 @@
+cmake_minimum_required(VERSION 3.15)
+project(${RunCMake_TEST} NONE)
+include(${RunCMake_TEST}.cmake)
diff --git a/Tests/RunCMake/UnityBuild/RunCMakeTest.cmake 
b/Tests/RunCMake/UnityBuild/RunCMakeTest.cmake
new file mode 100644
index 000..8e484d0
--- /dev/null
+++ b/Tests/RunCMake/UnityBuild/RunCMakeTest.cmake
@@ -0,0 +1,23 @@
+include(RunCMake)
+
+run_cmake(unitybuild_c)
+run_cmake(unitybuild_cxx)
+run_cmake(unitybuild_c_and_cxx)
+run_cmake(unitybuild_batchsize)
+run_cmake(unitybuild_default_batchsize)
+run_cmake(unitybuild_skip)
+run_cmake(unitybuild_code_before_and_after_include)
+run_cmake(unitybuild_c_no_unity_build)
+run_cmake(unitybuild_order)
+
+function(run_test name)
+  set(RunCMake_TEST_BINARY_DIR ${RunCMake_BINARY_DIR}/${name}-build)
+  set(RunCMake_TEST_NO_CLEAN 1)
+  run_cmake(${name})
+  run_cmake_command(${name}-build ${CMAKE_COMMAND} --build . --config Debug)
+  run_cmake_command(${name}-test ${CMAKE_CTEST_COMMAND} -C Debug)
+  unset(RunCMake_TEST_BINARY_DIR)
+  

[Cmake-commits] CMake branch, master, updated. v3.15.3-952-gfcba9c3

[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  fcba9c3baa00631407f493f97afe7e9cd1b844a7 (commit)
   via  e26f0e9dd58b839b880670d6000e7f1ebac1df94 (commit)
   via  f7085d7b0a0d4cced41669b498a3d03c4a1e65df (commit)
  from  f545428be08531d2561feba4854793775be83c39 (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=fcba9c3baa00631407f493f97afe7e9cd1b844a7
commit fcba9c3baa00631407f493f97afe7e9cd1b844a7
Merge: f545428 e26f0e9
Author: Brad King 
AuthorDate: Thu Sep 5 12:24:38 2019 +
Commit: Kitware Robot 
CommitDate: Thu Sep 5 08:24:50 2019 -0400

Merge topic 'cpack-zstd'

e26f0e9dd5 CPack: Add generator for .tar.zst packages
f7085d7b0a cmCPackArchiveGenerator: Code cleanup

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e26f0e9dd58b839b880670d6000e7f1ebac1df94
commit e26f0e9dd58b839b880670d6000e7f1ebac1df94
Author: Regina Pfeifer 
AuthorDate: Wed Aug 28 22:05:45 2019 +0200
Commit: Brad King 
CommitDate: Wed Sep 4 13:05:22 2019 -0400

CPack: Add generator for .tar.zst packages

diff --git a/Help/cpack_gen/archive.rst b/Help/cpack_gen/archive.rst
index b288aad..d455f4b 100644
--- a/Help/cpack_gen/archive.rst
+++ b/Help/cpack_gen/archive.rst
@@ -9,6 +9,7 @@ different formats:
   - TGZ (.tar.gz)
   - TXZ (.tar.xz)
   - TZ (.tar.Z)
+  - TZST (.tar.zst)
   - ZIP (.zip)
 
 Variables specific to CPack Archive generator
diff --git a/Help/release/dev/cpack-zstd.rst b/Help/release/dev/cpack-zstd.rst
new file mode 100644
index 000..e1e64a2
--- /dev/null
+++ b/Help/release/dev/cpack-zstd.rst
@@ -0,0 +1,5 @@
+cpack-zstd
+--
+
+* The :cpack_gen:`CPack Archive Generator` learned to generate `.tar.zst`
+  packages with Zstandard compression.
diff --git a/Source/CPack/cmCPackArchiveGenerator.cxx 
b/Source/CPack/cmCPackArchiveGenerator.cxx
index e9338f2..1271b08 100644
--- a/Source/CPack/cmCPackArchiveGenerator.cxx
+++ b/Source/CPack/cmCPackArchiveGenerator.cxx
@@ -46,6 +46,12 @@ cmCPackGenerator* 
cmCPackArchiveGenerator::CreateTZGenerator()
  ".tar.Z");
 }
 
+cmCPackGenerator* cmCPackArchiveGenerator::CreateTZSTGenerator()
+{
+  return new cmCPackArchiveGenerator(cmArchiveWrite::CompressZstd, "paxr",
+ ".tar.zst");
+}
+
 cmCPackGenerator* cmCPackArchiveGenerator::CreateZIPGenerator()
 {
   return new cmCPackArchiveGenerator(cmArchiveWrite::CompressNone, "zip",
diff --git a/Source/CPack/cmCPackArchiveGenerator.h 
b/Source/CPack/cmCPackArchiveGenerator.h
index 9bd1ede..f5be0aa 100644
--- a/Source/CPack/cmCPackArchiveGenerator.h
+++ b/Source/CPack/cmCPackArchiveGenerator.h
@@ -29,6 +29,7 @@ public:
   static cmCPackGenerator* CreateTGZGenerator();
   static cmCPackGenerator* CreateTXZGenerator();
   static cmCPackGenerator* CreateTZGenerator();
+  static cmCPackGenerator* CreateTZSTGenerator();
   static cmCPackGenerator* CreateZIPGenerator();
 
   /**
diff --git a/Source/CPack/cmCPackGeneratorFactory.cxx 
b/Source/CPack/cmCPackGeneratorFactory.cxx
index f230871..4d41049 100644
--- a/Source/CPack/cmCPackGeneratorFactory.cxx
+++ b/Source/CPack/cmCPackGeneratorFactory.cxx
@@ -54,6 +54,8 @@ cmCPackGeneratorFactory::cmCPackGeneratorFactory()
 cmCPackArchiveGenerator::CreateTXZGenerator);
 this->RegisterGenerator("TZ", "Tar Compress compression",
 cmCPackArchiveGenerator::CreateTZGenerator);
+this->RegisterGenerator("TZST", "Tar Zstandard compression",
+cmCPackArchiveGenerator::CreateTZSTGenerator);
 this->RegisterGenerator("ZIP", "ZIP file format",
 cmCPackArchiveGenerator::CreateZIPGenerator);
   }

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f7085d7b0a0d4cced41669b498a3d03c4a1e65df
commit f7085d7b0a0d4cced41669b498a3d03c4a1e65df
Author: Regina Pfeifer 
AuthorDate: Wed Aug 28 21:36:38 2019 +0200
Commit: Brad King 
CommitDate: Wed Sep 4 13:05:22 2019 -0400

cmCPackArchiveGenerator: Code cleanup

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index 2ff6c8c..decb39a 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -978,12 +978,6 @@ set(CPACK_SRCS
   CPack/cmCPackNSISGenerator.cxx
   CPack/cmCPackNuGetGenerator.cxx
   CPack/cmCPackSTGZGenerator.cxx
-  CPack/cmCPackTGZGenerator.cxx
-  CPack/cmCPackTXZGenerator.cxx
-  CPack/cmCPackTarBZip2Generator.cxx
-  CPack/cmCPackTarCompressGenerator.cxx
-  CPack/cmCPackZIPGenerator.cxx
-  CPack/cmCPack7zGenerator.cxx
   )
 # CPack 

[Cmake-commits] CMake branch, master, updated. v3.15.3-949-gf545428

[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  f545428be08531d2561feba4854793775be83c39 (commit)
  from  ee15bc7d7e7707fd8d7db92645c2c56a5df0f681 (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=f545428be08531d2561feba4854793775be83c39
commit f545428be08531d2561feba4854793775be83c39
Author: Kitware Robot 
AuthorDate: Thu Sep 5 00:01:06 2019 -0400
Commit: Kitware Robot 
CommitDate: Thu Sep 5 00:01:06 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 5f6e9bb..545b0a9 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 15)
-set(CMake_VERSION_PATCH 20190904)
+set(CMake_VERSION_PATCH 20190905)
 #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

Re: [CMake] The connection to cmake-server was terminated unexpectedly [cms-client] cmake-server exited with status null (SIGSEGV)

[Christopher Dawes]

Awesome thank you so much! So i’ve upgraded to 3.15.3 and it’s told me 
perfectly my issue. So I have an override script (FindLibXml2.cmake):

*** START CODE ***
# FindLibXml2.cmake
#
# A wrapper around CMake's FindLibXml2 which provides an imported target.

# Find LibXml2 using the built-in module
set(_cmake_module_path "${CMAKE_MODULE_PATH}")
set(CMAKE_MODULE_PATH)
include(FindLibXml2)
set(CMAKE_MODULE_PATH "${_cmake_module_path}")

if(LibXml2_FOUND AND NOT TARGET LibXml2::LibXml2)
  add_library(LibXml2::LibXml2 INTERFACE IMPORTED)
  set_target_properties(LibXml2::LibXml2 PROPERTIES
INTERFACE_LINK_LIBRARIES "${LIBXML2_LIBRARIES}"
INTERFACE_INCLUDE_DIRECTORIES "${LIBXML2_INCLUDE_DIR}")
else()
  #https://github.com/Homebrew/homebrew-core/issues/6186
  if(APPLE)
get_target_property(id LibXml2::LibXml2 INTERFACE_INCLUDE_DIRECTORIES)
list(REMOVE_ITEM id "/usr/include/libxml2")
set_target_properties(LibXml2::LibXml2 PROPERTIES 
INTERFACE_INCLUDE_DIRECTORIES "${id}")
  endif()
endif()

*** END CODE ***

So the issue was:
  set(CMAKE_MODULE_PATH)

doesn’t work in cmake-server; also unset(CMAKE_MODULE_PATH) didn’t work either, 
when i do:

set(CMAKE_MODULE_PATH “/nonexistent”)

it all comes good; for some reason i think unset isn’t quite happy on 
cmake-server.

Many thanks again for your quick response!

Christopher Dawes
Principal Architect, EFTLab

M: +44 (0)7899 842 759
E: christopher.da...@eftlab.com
A: 109 Brighton Road, Sandgate, QLD 4017

IMPORTANT NOTICE
This message contains confidential information and is intended only for the 
addressee(s). E-mail transmission cannot be guaranteed to be secure or 
error-free as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses. EFTlab Pty Ltd cannot accept 
liability for any errors or omissions in the contents of this message, which 
may arise as a result of e-mail transmission. Please note that EFTlab Pty Ltd 
may monitor, analyse and archive email traffic, data and the content of email 
for the purposes of security, legal compliance and staff training. If you have 
received this email in error please notify us at 
supp...@eftlab.com.au.

On 4 Sep 2019, at 19:39, Kyle Edwards via CMake 
mailto:cmake@cmake.org>> wrote:

On Wed, 2019-09-04 at 14:12 -0400, fdk17 wrote:
https://github.com/microsoft/vscode-cmake-tools/issues/752 states
that it ran out of stack and the log shows what looks like to be
involved with a recursive loop in some CMakeLists.txt.  A call depth
of 27491 seems a bit excessive.

After the second call to FindPackage it just seems to be doing the
same thing over and over again.
I'd think a newer version of CMake would complain about too much
recursion in the project files.

Indeed, this was added in 3.14:

https://cmake.org/cmake/help/v3.14/variable/CMAKE_MAXIMUM_RECURSION_DEP
TH.html
Kyle
--

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

Re: [CMake] The connection to cmake-server was terminated unexpectedly [cms-client] cmake-server exited with status null (SIGSEGV)

[Craig Scott]

On Thu, Sep 5, 2019 at 7:56 AM Christopher Dawes <
christopher.da...@eftlab.com> wrote:

> Awesome thank you so much! So i’ve upgraded to 3.15.3 and it’s told me
> perfectly my issue. So I have an override script (FindLibXml2.cmake):
>
> *** START CODE ***
> # FindLibXml2.cmake
> #
> # A wrapper around CMake's FindLibXml2 which provides an imported target.
>
> # Find LibXml2 using the built-in module
> set(_cmake_module_path "${CMAKE_MODULE_PATH}")
> set(CMAKE_MODULE_PATH)
> include(FindLibXml2)
> set(CMAKE_MODULE_PATH "${_cmake_module_path}")
>
> if(LibXml2_FOUND AND NOT TARGET LibXml2::LibXml2)
>   add_library(LibXml2::LibXml2 INTERFACE IMPORTED)
>   set_target_properties(LibXml2::LibXml2 PROPERTIES
> INTERFACE_LINK_LIBRARIES "${LIBXML2_LIBRARIES}"
> INTERFACE_INCLUDE_DIRECTORIES "${LIBXML2_INCLUDE_DIR}")
> else()
>   #https://github.com/Homebrew/homebrew-core/issues/6186
>   if(APPLE)
> get_target_property(id LibXml2::LibXml2 INTERFACE_INCLUDE_DIRECTORIES)
> list(REMOVE_ITEM id "/usr/include/libxml2")
> set_target_properties(LibXml2::LibXml2 PROPERTIES
> INTERFACE_INCLUDE_DIRECTORIES "${id}")
>   endif()
> endif()
>
> *** END CODE ***
>
> So the issue was:
>   set(CMAKE_MODULE_PATH)
>
> doesn’t work in cmake-server; also unset(CMAKE_MODULE_PATH) didn’t work
> either, when i do:
>
> set(CMAKE_MODULE_PATH “/nonexistent”)
>
> it all comes good; for some reason i think unset isn’t quite happy on
> cmake-server.
>

Check that you don't also have a CMAKE_MODULE_PATH cache variable as well.
If you unset the non-cache variable, it will effectively unmask the cache
variable of the same name.





> Many thanks again for your quick response!
>
> *Christopher Dawes*
> *Principal Architect, EFTLab*
>
> *M:* +44 (0)7899 842 759
> *E:* christopher.da...@eftlab.com
> *A:* 109 Brighton Road, Sandgate, QLD 4017
>
> *IMPORTANT NOTICE*
> This message contains confidential information and is intended only for
> the addressee(s). E-mail transmission cannot be guaranteed to be secure or
> error-free as information could be intercepted, corrupted, lost, destroyed,
> arrive late or incomplete, or contain viruses. EFTlab Pty Ltd cannot accept
> liability for any errors or omissions in the contents of this message,
> which may arise as a result of e-mail transmission. Please note that EFTlab
> Pty Ltd may monitor, analyse and archive email traffic, data and the
> content of email for the purposes of security, legal compliance and staff
> training. If you have received this email in error please notify us at
> supp...@eftlab.com.au.
>
> On 4 Sep 2019, at 19:39, Kyle Edwards via CMake  wrote:
>
> On Wed, 2019-09-04 at 14:12 -0400, fdk17 wrote:
>
> https://github.com/microsoft/vscode-cmake-tools/issues/752 states
> that it ran out of stack and the log shows what looks like to be
> involved with a recursive loop in some CMakeLists.txt.  A call depth
> of 27491 seems a bit excessive.
>
> After the second call to FindPackage it just seems to be doing the
> same thing over and over again.
> I'd think a newer version of CMake would complain about too much
> recursion in the project files.
>
>
> Indeed, this was added in 3.14:
>
> https://cmake.org/cmake/help/v3.14/variable/CMAKE_MAXIMUM_RECURSION_DEP
> TH.html
> Kyle
> --
>
> 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
>


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

Re: [CMake] The connection to cmake-server was terminated unexpectedly [cms-client] cmake-server exited with status null (SIGSEGV)

[Kyle Edwards via CMake]

On Wed, 2019-09-04 at 14:12 -0400, fdk17 wrote:
> https://github.com/microsoft/vscode-cmake-tools/issues/752 states
> that it ran out of stack and the log shows what looks like to be
> involved with a recursive loop in some CMakeLists.txt.  A call depth
> of 27491 seems a bit excessive.
> 
> After the second call to FindPackage it just seems to be doing the
> same thing over and over again.
> I'd think a newer version of CMake would complain about too much
> recursion in the project files.

Indeed, this was added in 3.14:

https://cmake.org/cmake/help/v3.14/variable/CMAKE_MAXIMUM_RECURSION_DEP
TH.html
Kyle
-- 

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] The connection to cmake-server was terminated unexpectedly [cms-client] cmake-server exited with status null (SIGSEGV)

[fdk17]

https://github.com/microsoft/vscode-cmake-tools/issues/752 states that it ran 
out of stack and the log shows what looks like to be involved with a recursive 
loop in some CMakeLists.txt. A call depth of 27491 seems a bit excessive.

After the second call to FindPackage it just seems to be doing the same thing 
over and over again.
I'd think a newer version of CMake would complain about too much recursion in 
the project files.

Does the project work on the command line without involving VSCode?
It could be something different in the environment if it works on the command 
line but not as server instance in VSCode.

--
F

On Wed, Sep 4, 2019, at 12:22 PM, Christopher Dawes wrote:
> Hi there, we are experiencing a crash when working with VSCode on Ubuntu:
> 
> Brief Issue Summary

> When starting up VSCode using the CMake extension i get this error on all my 
> projects, the application terminates pretty quickly. What’s happening is 
> cmake server is spawned and then crashes; i’m afraid i’m uncertain what 
> commands are exchanged. I logged the issue against the cmake extension here  
> https://github.com/microsoft/vscode-cmake-tools/issues/752 however it looks 
> like the issue is with cmake rather than the way it’s being used.

> Platform and Versions

>  * Operating System: Ubuntu 18.04
>  * CMake Version: 3.10.2
>  * VSCode Version: 1.37.1
>  * CMake Tools Extension Version: 1.13
>  * Compiler/Toolchain: GCC 7.4.0-1ubuntu1~18.04.1 with Ninja
> Other Notes/Information

> I've run with debug symbols however it's too big (33MB) to attach here, see

> https://www.dropbox.com/s/cl7z4cxd5oyuvbr/with_symbols.txt?dl=0

> Here's a small excerpt:
> Thread 1 (Thread 0x7fce40c3a780 (LWP 28685)):
#0  std::__cxx11::basic_string, std::allocator >::_M_length (this=, __length=) 
at /usr/include/c++/7/bits/basic_string.h:172
No locals.
#1  std::__cxx11::basic_string, std::allocator >::_M_set_length (__n=, this=) 
at /usr/include/c++/7/bits/basic_string.h:205
No locals.
#2  std::__cxx11::basic_string, std::allocator >::basic_string 
(this=0x7ffdee7d5e40) at /usr/include/c++/7/bits/basic_string.h:423
No locals.
#3  cmsys::SystemTools::FileIsDirectory (inName=...) at 
./Source/kwsys/SystemTools.cxx:2865
length = 
name = 
local_buffer = 
string_buffer = 
last = 
fs = 
#4  0x55d2c7efa231 in cmListFile::ParseFile 
(this=this@entry=0x7ffdee7d7010, filename=0x55d2ca803700 
"/usr/local/bp/share/cmake/FindLibXml2.cmake", messenger=0x55d2c8da6110, 
lfbt=...) at ./Source/cmListFileCache.cxx:139
parseError = 
#5  0x55d2c7ca8c63 in cmMakefile::ReadDependentFile (this=0x55d2c8e139a0, 
filename=, noPolicyScope=noPolicyScope@entry=false) at 
./Source/cmMakefile.cxx:444
filenametoread = {static npos = 18446744073709551615, _M_dataplus = {> 
= {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803700 
"/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, 
{_M_local_buf = "-\000\000\000\000\000\000\000\v\000\000\000\000\000\000", 
_M_allocated_capacity = 45}}
incScope = {Makefile = 0x55d2c8e139a0, NoPolicyScope = false, 
CheckCMP0011 = false, ReportError = true}
listFile = {Functions = { >> = {_M_impl = {> = 
{<__gnu_cxx::new_allocator> = {}, }, _M_start = 0x0, _M_finish = 0x0, 
_M_end_of_storage = 0x0}}, }}
#6  0x55d2c7d8e3bb in cmIncludeCommand::InitialPass (this=0x55d2ca8034c0, 
args=...) at ./Source/cmIncludeCommand.cxx:123
readit = 
optional = 
noPolicyScope = 
fname = {static npos = 18446744073709551615, _M_dataplus = {> = 
{<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803640 
"/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, 
{_M_local_buf = "+\000\000\000\000\000\000\000ml2\000\000\000\000", 
_M_allocated_capacity = 43}}
resultVarName = {static npos = 18446744073709551615, _M_dataplus = {> = 
{<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x7ffdee7d7120 ""}, 
_M_string_length = 0, {_M_local_buf = 
"\000\000\000\000[\000\000\000Pc\357\310\322U\000", _M_allocated_capacity = 
390842023936}}
fname_abs = {static npos = 18446744073709551615, _M_dataplus = {> = 
{<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803560 
"/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, 
{_M_local_buf = "-\000\000\000\000\000\000\000`5\200\312\322U\000", 
_M_allocated_capacity = 45}}
gg = 0x55d2c8df16a0
listFile = {static npos = 18446744073709551615, _M_dataplus = {> = 
{<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803680 
"/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, 
{_M_local_buf = "-", '\000' , _M_allocated_capacity = 45}}
#7  0x55d2c7d2709c in cmCommand::InvokeInitialPass (this=0x55d2ca8034c0, 
args=..., status=...) at ./Source/cmCommand.cxx:19
expandedArguments = {, std::allocator >, std::allocator, std::allocator 
> > >> = {_M_impl = {, std::allocator > >> = {<__gnu_cxx::new_allocator, 

[CMake] The connection to cmake-server was terminated unexpectedly [cms-client] cmake-server exited with status null (SIGSEGV)

[Christopher Dawes]

Hi there, we are experiencing a crash when working with VSCode on Ubuntu:

Brief Issue Summary

When starting up VSCode using the CMake extension i get this error on all my 
projects, the application terminates pretty quickly. What’s happening is cmake 
server is spawned and then crashes; i’m afraid i’m uncertain what commands are 
exchanged. I logged the issue against the cmake extension here 
https://github.com/microsoft/vscode-cmake-tools/issues/752 however it looks 
like the issue is with cmake rather than the way it’s being used.

Platform and Versions

  *   Operating System: Ubuntu 18.04
  *   CMake Version: 3.10.2
  *   VSCode Version: 1.37.1
  *   CMake Tools Extension Version: 1.13
  *   Compiler/Toolchain: GCC 7.4.0-1ubuntu1~18.04.1 with Ninja

Other Notes/Information

I've run with debug symbols however it's too big (33MB) to attach here, see

https://www.dropbox.com/s/cl7z4cxd5oyuvbr/with_symbols.txt?dl=0

Here's a small excerpt:

Thread 1 (Thread 0x7fce40c3a780 (LWP 28685)):
#0  std::__cxx11::basic_string, std::allocator >::_M_length (this=, __length=) 
at /usr/include/c++/7/bits/basic_string.h:172
No locals.
#1  std::__cxx11::basic_string, std::allocator >::_M_set_length (__n=, this=) 
at /usr/include/c++/7/bits/basic_string.h:205
No locals.
#2  std::__cxx11::basic_string, std::allocator >::basic_string 
(this=0x7ffdee7d5e40) at /usr/include/c++/7/bits/basic_string.h:423
No locals.
#3  cmsys::SystemTools::FileIsDirectory (inName=...) at 
./Source/kwsys/SystemTools.cxx:2865
length =
name =
local_buffer =
string_buffer =
last =
fs =
#4  0x55d2c7efa231 in cmListFile::ParseFile 
(this=this@entry=0x7ffdee7d7010, filename=0x55d2ca803700 
"/usr/local/bp/share/cmake/FindLibXml2.cmake", messenger=0x55d2c8da6110, 
lfbt=...) at ./Source/cmListFileCache.cxx:139
parseError =
#5  0x55d2c7ca8c63 in cmMakefile::ReadDependentFile (this=0x55d2c8e139a0, 
filename=, noPolicyScope=noPolicyScope@entry=false) at 
./Source/cmMakefile.cxx:444
filenametoread = {static npos = 18446744073709551615, _M_dataplus = {> 
= {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803700 
"/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, 
{_M_local_buf = "-\000\000\000\000\000\000\000\v\000\000\000\000\000\000", 
_M_allocated_capacity = 45}}
incScope = {Makefile = 0x55d2c8e139a0, NoPolicyScope = false, 
CheckCMP0011 = false, ReportError = true}
listFile = {Functions = { >> = {_M_impl = {> = 
{<__gnu_cxx::new_allocator> = {}, }, _M_start = 0x0, _M_finish = 0x0, 
_M_end_of_storage = 0x0}}, }}
#6  0x55d2c7d8e3bb in cmIncludeCommand::InitialPass (this=0x55d2ca8034c0, 
args=...) at ./Source/cmIncludeCommand.cxx:123
readit =
optional =
noPolicyScope =
fname = {static npos = 18446744073709551615, _M_dataplus = {> = 
{<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803640 
"/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, 
{_M_local_buf = "+\000\000\000\000\000\000\000ml2\000\000\000\000", 
_M_allocated_capacity = 43}}
resultVarName = {static npos = 18446744073709551615, _M_dataplus = {> = 
{<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x7ffdee7d7120 ""}, 
_M_string_length = 0, {_M_local_buf = 
"\000\000\000\000[\000\000\000Pc\357\310\322U\000", _M_allocated_capacity = 
390842023936}}
fname_abs = {static npos = 18446744073709551615, _M_dataplus = {> = 
{<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803560 
"/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, 
{_M_local_buf = "-\000\000\000\000\000\000\000`5\200\312\322U\000", 
_M_allocated_capacity = 45}}
gg = 0x55d2c8df16a0
listFile = {static npos = 18446744073709551615, _M_dataplus = {> = 
{<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x55d2ca803680 
"/usr/local/bp/share/cmake/FindLibXml2.cmake"}, _M_string_length = 43, 
{_M_local_buf = "-", '\000' , _M_allocated_capacity = 45}}
#7  0x55d2c7d2709c in cmCommand::InvokeInitialPass (this=0x55d2ca8034c0, 
args=..., status=...) at ./Source/cmCommand.cxx:19
expandedArguments = {, std::allocator >, std::allocator, std::allocator 
> > >> = {_M_impl = {, std::allocator > >> = {<__gnu_cxx::new_allocator, 
std::allocator > >> = {}, }, _M_start = 0x55d2ca8013a0, _M_finish = 
0x55d2ca8013c0, _M_end_of_storage = 0x55d2ca8013c0}}, }
#8  0x55d2c7ca7326 in cmMakefile::ExecuteCommand 
(this=this@entry=0x55d2c8e139a0, lff=..., status=...) at 
./Source/cmMakefile.cxx:277
invokeSucceeded =
hadNestedError =
pcmd = {_M_t = {_M_t = { >> = { >> = {, true>> = {> = {}, }, }, > = 
{_M_head_impl = 0x55d2ca8034c0}, }, }}}
proto =
result = true
name = {static npos = 18446744073709551615, _M_dataplus = {> = 
{<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x7ffdee7d7400 "include"}, 
_M_string_length = 7, {_M_local_buf = "include\000p\205\336\310\322U\000", 
_M_allocated_capacity = 

[cmake-developers] [ANNOUNCE] CMake 3.15.3 available for download

[Robert Maynard via cmake-developers]

We are pleased to announce that CMake 3.15.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.15.3 since 3.15.2:

Brad King (13):
  Flang: Implement MSVC runtime library abstraction
  CTest: Fix --show-only=json-v1 output with REQUIRED_FILES property
  cmGlobalGenerator: Fix CheckCompilerIdCompatibility local var lifetime
  cmAffinity: Add include for CPU_ZERO on Alpine Linux
  find_path: Fix crash on empty old-style list of names
  fileapi: Fix codemodel v2 target file name for CMP0037 OLD behavior
  FindBoost: Simplify conditional block for last known version
  FindBoost: Remove incorrect 1.70 timer dependency
  FindBoost: Unwrap compatibility INTERFACE targets for legacy variables
  FindBoost: Add support for Boost 1.71
  FindBoost: Clarify role of legacy variables in warning message
  FindBoost: Tolerate future Boost INTERFACE libraries
  CMake 3.15.3

Chuck Atkins (1):
  CrayPrgEnv: Change default linking mode based on PE version

M Furkan USLU (1):
  ccmake: handle cache entries with empty STRINGS property

Marvin Schmidt (1):
  libarchive: We now require at least version 3.3.3

Robert Maynard (1):
  FindMPI: Restore MPI__COMPILE_FLAGS and MPI__COMPILE_OPTIONS

Sebastian Holtermann (3):
  Ninja: Add support for ADDITIONAL_CLEAN_FILES in custom targets
  Tests: Extend MakeClean test to test various target types
  Autogen: Fix AUTOUIC segfault, when file includes colliding ui_*.h file
-- 

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

[CMake] [ANNOUNCE] CMake 3.15.3 available for download

[Robert Maynard via CMake]

We are pleased to announce that CMake 3.15.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.15.3 since 3.15.2:

Brad King (13):
  Flang: Implement MSVC runtime library abstraction
  CTest: Fix --show-only=json-v1 output with REQUIRED_FILES property
  cmGlobalGenerator: Fix CheckCompilerIdCompatibility local var lifetime
  cmAffinity: Add include for CPU_ZERO on Alpine Linux
  find_path: Fix crash on empty old-style list of names
  fileapi: Fix codemodel v2 target file name for CMP0037 OLD behavior
  FindBoost: Simplify conditional block for last known version
  FindBoost: Remove incorrect 1.70 timer dependency
  FindBoost: Unwrap compatibility INTERFACE targets for legacy variables
  FindBoost: Add support for Boost 1.71
  FindBoost: Clarify role of legacy variables in warning message
  FindBoost: Tolerate future Boost INTERFACE libraries
  CMake 3.15.3

Chuck Atkins (1):
  CrayPrgEnv: Change default linking mode based on PE version

M Furkan USLU (1):
  ccmake: handle cache entries with empty STRINGS property

Marvin Schmidt (1):
  libarchive: We now require at least version 3.3.3

Robert Maynard (1):
  FindMPI: Restore MPI__COMPILE_FLAGS and MPI__COMPILE_OPTIONS

Sebastian Holtermann (3):
  Ninja: Add support for ADDITIONAL_CLEAN_FILES in custom targets
  Tests: Extend MakeClean test to test various target types
  Autogen: Fix AUTOUIC segfault, when file includes colliding ui_*.h file
-- 

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 annotated tag, v3.15.3, created. v3.15.3

[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.15.3 has been created
at  842f4e2244ec87b814624c97be6456b3d68d3f6c (tag)
   tagging  26a0e200e5f4abe8268235c9fdb23a2612a1b3b1 (commit)
  replaces  v3.15.2
 tagged by  Brad King
on  Wed Sep 4 10:56:34 2019 -0400

- Log -
CMake 3.15.3
-BEGIN PGP SIGNATURE-

iQJKBAABCgA0FiEExsJlMku+vcNQtRPQLSzvEDSSFoQFAl1v0KIWHGJyYWQua2lu
Z0BraXR3YXJlLmNvbQAKCRAtLO8QNJIWhJf0D/9unhBq9FGp2DD/kjXBfJFmMkyC
ABguTSYX/guCHDHTMlBQx01r+fllpAihFg8m/XrU3fOuBJRLHHbMEn5WR9EmXaRq
UgKYfc5f0B2DUf0bFAf1v0QLtpZgleipd26wOSloWjs94tBn6o9IV2UdBpxs9b5U
Ay7IG7DPuJqFRqocuZVC9iS/H0uZ6n8kg/0patgqL2hv/wE9KVPIZAng9TVQA5hz
tQEv419gpvRqA3Wgpoj/+oFgS3EcrVymaIQKE478cqnVd5WmdoP84lnDYbC7DCXe
IjBlGbNPo1CTTzQ6glvzmanWRFe4fgmMrJ/nSOS09h78DZMUyPTrbTpctb3s/7e1
tvbejZgrrH+R3TJvNh4ZR2l05g3Vy9m2HQYUaPXP1viGQD3u6ymXCUqx/iQt19CG
xGZFXqQR5IRAozjrZ6KNgJ/UG1ZwXwBhPeW4XNSBE/PRXoW4U8tGvwou7gCnZORg
1i7I1ABweIaU0mwk8LF3++Hv5vkcj9LsiC7TgCW8xjEhVbONTwsuUpkAXTz2VtKq
Ekgk0+p5vXsiiSpUvnCOPFURk2eDJVhVXOlsY8ybnQ6ae8Ewwgoxk+W+Oa2aZ8B2
45STj193kGoWzXboBHGeIulHnvmmrxkwoXwun+oNIZm5Hc0s4n9a2ZHgpngUx+lo
idvR++raJrI7BAc1Ww==
=gzq0
-END PGP SIGNATURE-

Brad King (27):
  Flang: Implement MSVC runtime library abstraction
  Merge branch 'msvc-runtime-library-flang' into release-3.15
  Merge branch 'ccmake-crash-on-empty-strings-property' into release-3.15
  Merge branch 'FindMPI-restore-flag-vars' into release-3.15
  Merge branch 'CrayPrgEnv-update-link-type-detection' into release-3.15
  CTest: Fix --show-only=json-v1 output with REQUIRED_FILES property
  Merge branch 'ctest-json-REQUIRED_FILES' into release-3.15
  cmGlobalGenerator: Fix CheckCompilerIdCompatibility local var lifetime
  cmAffinity: Add include for CPU_ZERO on Alpine Linux
  Merge branch 'ninja_additional_clean_files_custom_target' into 
release-3.15
  Merge branch 'libarchive-requirement' into release-3.15
  Merge branch 'cmGlobalGenerator-compilerId-lifetime' into release-3.15
  Merge branch 'alpine-cpu_zero' into release-3.15
  Merge branch 'autogen_fix_use_after_move' into release-3.15
  find_path: Fix crash on empty old-style list of names
  Merge branch 'backport-find-no-name' into release-3.15
  fileapi: Fix codemodel v2 target file name for CMP0037 OLD behavior
  Merge branch 'fileapi-CMP0037-OLD' into release-3.15
  FindBoost: Simplify conditional block for last known version
  FindBoost: Remove incorrect 1.70 timer dependency
  FindBoost: Unwrap compatibility INTERFACE targets for legacy variables
  FindBoost: Add support for Boost 1.71
  Merge branch 'FindBoost-1.71' into release-3.15
  FindBoost: Clarify role of legacy variables in warning message
  FindBoost: Tolerate future Boost INTERFACE libraries
  Merge branch 'FindBoost-1.71' into release-3.15
  CMake 3.15.3

Chuck Atkins (1):
  CrayPrgEnv: Change default linking mode based on PE version

M Furkan USLU (1):
  ccmake: handle cache entries with empty STRINGS property

Marvin Schmidt (1):
  libarchive: We now require at least version 3.3.3

Robert Maynard (1):
  FindMPI: Restore MPI__COMPILE_FLAGS and MPI__COMPILE_OPTIONS

Sebastian Holtermann (3):
  Ninja: Add support for ADDITIONAL_CLEAN_FILES in custom targets
  Tests: Extend MakeClean test to test various target types
  Autogen: Fix AUTOUIC segfault, when file includes colliding ui_*.h file

---


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.15.2-34-g26a0e20

[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  26a0e200e5f4abe8268235c9fdb23a2612a1b3b1 (commit)
  from  7a8bd12926c32f709cc162ba931484c1b5820363 (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.15.2-982-gee15bc7

[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  ee15bc7d7e7707fd8d7db92645c2c56a5df0f681 (commit)
   via  26a0e200e5f4abe8268235c9fdb23a2612a1b3b1 (commit)
  from  aef152b91d9f56af87ca2b9618f07228e5f3c463 (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=ee15bc7d7e7707fd8d7db92645c2c56a5df0f681
commit ee15bc7d7e7707fd8d7db92645c2c56a5df0f681
Merge: aef152b 26a0e20
Author: Brad King 
AuthorDate: Wed Sep 4 10:36:51 2019 -0400
Commit: Brad King 
CommitDate: Wed Sep 4 10:36:51 2019 -0400

Merge branch 'release-3.15'


---

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, master, updated. v3.15.2-980-gaef152b

[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  aef152b91d9f56af87ca2b9618f07228e5f3c463 (commit)
   via  790db8d477cfaf10b227d6d7a7ca2c0d7d8aaf62 (commit)
   via  7a8bd12926c32f709cc162ba931484c1b5820363 (commit)
   via  907d3ed824d8b82525c687747662b358accded9c (commit)
   via  2d357b7a682070fc98f520212d82efa821fc821c (commit)
  from  09032f09f8d2b4f7af658060ef434083f9d6a0d4 (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=aef152b91d9f56af87ca2b9618f07228e5f3c463
commit aef152b91d9f56af87ca2b9618f07228e5f3c463
Merge: 790db8d 7a8bd12
Author: Brad King 
AuthorDate: Wed Sep 4 09:43:43 2019 -0400
Commit: Brad King 
CommitDate: Wed Sep 4 09:43:43 2019 -0400

Merge branch 'release-3.15'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=790db8d477cfaf10b227d6d7a7ca2c0d7d8aaf62
commit 790db8d477cfaf10b227d6d7a7ca2c0d7d8aaf62
Merge: 09032f0 907d3ed
Author: Brad King 
AuthorDate: Wed Sep 4 13:43:07 2019 +
Commit: Kitware Robot 
CommitDate: Wed Sep 4 09:43:18 2019 -0400

Merge topic 'FindBoost-1.71'

907d3ed824 FindBoost: Tolerate future Boost INTERFACE libraries
2d357b7a68 FindBoost: Clarify role of legacy variables in warning message

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


---

Summary of changes:
 Modules/FindBoost.cmake | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)


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.15.2-33-g7a8bd12

[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  7a8bd12926c32f709cc162ba931484c1b5820363 (commit)
   via  907d3ed824d8b82525c687747662b358accded9c (commit)
   via  2d357b7a682070fc98f520212d82efa821fc821c (commit)
  from  3b8fa496e7a9482cb4592e9f36b54f5b1bc3cdea (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/FindBoost.cmake | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)


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