[Cmake-commits] CMake branch, master, updated. v3.7.0-rc1-165-g2fb8e5b

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  2fb8e5b1c46ea586233b19e612ba174aa74d004c (commit)
  from  656ebaca3be50e92edca3d9628b784f5ff1e6a99 (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=2fb8e5b1c46ea586233b19e612ba174aa74d004c
commit 2fb8e5b1c46ea586233b19e612ba174aa74d004c
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Tue Oct 11 00:01:06 2016 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Tue Oct 11 00:01:06 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index da91b74..e35ea30 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 7)
-set(CMake_VERSION_PATCH 20161010)
+set(CMake_VERSION_PATCH 20161011)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-394-g67c528c

[Stephen Kelly]

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, next has been updated
   via  67c528c03d2c598e4922f932c5598d5da91bc408 (commit)
   via  6f0cee13fdadd4573e9dd57c1713d9a674abb713 (commit)
   via  a60ea0a957978495bd8a2dacb17447ef9e0bc694 (commit)
   via  8b3af6a7ca2d4938568df8dc70c9d44c62ba9fe1 (commit)
   via  49afda6b4e94d7747058bf5174bda6c333c921c6 (commit)
   via  91bc8ec9b8941f15c9adca532afa2dea9d1c1fa1 (commit)
   via  3743af8aa6db573370b5f4d10b06d35ab507b894 (commit)
   via  780b5ea7c5b416e17f469235c08679fa3417262b (commit)
   via  b9badf851e865ef7076abb49904785b026909a49 (commit)
   via  b2c6630c566344c4289cf312adfa45f939820f54 (commit)
  from  17bef2cd6780731f77be1383f74ddb5d9c44bffc (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=67c528c03d2c598e4922f932c5598d5da91bc408
commit 67c528c03d2c598e4922f932c5598d5da91bc408
Merge: 17bef2c 6f0cee1
Author: Stephen Kelly 
AuthorDate: Mon Oct 10 18:44:22 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Oct 10 18:44:22 2016 -0400

Merge topic 'extract-cmRulePlaceholderExpander' into next

6f0cee13 cmRulePlaceholderExpander: Port clients to direct-use
a60ea0a9 cmRulePlaceholderExpander: Extract from cmLocalGenerator
8b3af6a7 cmLocalGenerator: Use strings instead of a Target in rule 
replacement
49afda6b cmLocalGenerator: Use a converter in rule replacement API
91bc8ec9 cmLocalGenerator: Store variable replacements as state
3743af8a cmLocalGenerator: Merge loops which populate mapping
780b5ea7 cmLocalGenerator: Populate variable mapping for all replacements
b9badf85 cmLocalGenerator: Extract compiler option replacement from loop
b2c6630c cmLocalGenerator: Populate a container of mappings for replacements


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6f0cee13fdadd4573e9dd57c1713d9a674abb713
commit 6f0cee13fdadd4573e9dd57c1713d9a674abb713
Author: Stephen Kelly 
AuthorDate: Sun Oct 9 10:34:50 2016 +0200
Commit: Stephen Kelly 
CommitDate: Tue Oct 11 00:43:48 2016 +0200

cmRulePlaceholderExpander: Port clients to direct-use

Add a factory function to cmLocalGenerator so that variableMappings can
be provided from it, and so that Ninja can always have a hard-coded
TargetImpLib.

diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index 615168d..1c3a97d 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -133,6 +133,13 @@ cmLocalGenerator::cmLocalGenerator(cmGlobalGenerator* gg, 
cmMakefile* makefile)
   }
 }
 
+cmRulePlaceholderExpander* cmLocalGenerator::CreateRulePlaceholderExpander()
+  const
+{
+  return new cmRulePlaceholderExpander(this->Compilers, this->VariableMappings,
+   this->CompilerSysroot);
+}
+
 cmLocalGenerator::~cmLocalGenerator()
 {
   cmDeleteAll(this->GeneratorTargets);
@@ -561,17 +568,6 @@ cmState::Snapshot cmLocalGenerator::GetStateSnapshot() 
const
   return this->Makefile->GetStateSnapshot();
 }
 
-void cmLocalGenerator::ExpandRuleVariables(cmOutputConverter* outputConverter,
-   std::string& s,
-   const RuleVariables& replaceValues)
-{
-  cmRulePlaceholderExpander rulePlaceholderExpander(
-this->Compilers, this->VariableMappings, this->CompilerSysroot);
-  rulePlaceholderExpander.SetTargetImpLib(this->TargetImplib);
-  rulePlaceholderExpander.ExpandRuleVariables(outputConverter, s,
-  replaceValues);
-}
-
 const char* cmLocalGenerator::GetRuleLauncher(cmGeneratorTarget* target,
   const std::string& prop)
 {
diff --git a/Source/cmLocalGenerator.h b/Source/cmLocalGenerator.h
index 6f8426d..055e1a9 100644
--- a/Source/cmLocalGenerator.h
+++ b/Source/cmLocalGenerator.h
@@ -24,6 +24,7 @@ class cmComputeLinkInformation;
 class cmCustomCommandGenerator;
 class cmGeneratorTarget;
 class cmGlobalGenerator;
+class cmRulePlaceholderExpander;
 class cmMakefile;
 class cmSourceFile;
 class cmLinkLineComputer;
@@ -85,6 +86,8 @@ public:
 return this->GlobalGenerator;
   }
 
+  virtual cmRulePlaceholderExpander* CreateRulePlaceholderExpander() const;
+
   std::string GetLinkLibsCMP0065(std::string const& linkLanguage,
  cmGeneratorTarget& tgt) const;
 
@@ -218,10 +221,6 @@ public:
   // preprocessed files and assembly files.
   void GetIndividualFileTargets(std::vector&) {}
 
-  struct 

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-384-g17bef2c

[Stephen Kelly]

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, next has been updated
   via  17bef2cd6780731f77be1383f74ddb5d9c44bffc (commit)
   via  9dcfa5f09b2b6345c3a83612a69d3e94bc43aac9 (commit)
  from  885c6f5f348a45174cf5e3a799dc8c0f13c37e67 (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=17bef2cd6780731f77be1383f74ddb5d9c44bffc
commit 17bef2cd6780731f77be1383f74ddb5d9c44bffc
Merge: 885c6f5 9dcfa5f
Author: Stephen Kelly 
AuthorDate: Mon Oct 10 18:05:12 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Oct 10 18:05:12 2016 -0400

Merge topic 'extract-cmRulePlaceholderExpander' into next

9dcfa5f0 Fix output bug


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9dcfa5f09b2b6345c3a83612a69d3e94bc43aac9
commit 9dcfa5f09b2b6345c3a83612a69d3e94bc43aac9
Author: Stephen Kelly 
AuthorDate: Tue Oct 11 00:04:49 2016 +0200
Commit: Stephen Kelly 
CommitDate: Tue Oct 11 00:04:49 2016 +0200

Fix output bug

diff --git a/Source/cmRulePlaceholderExpander.cxx 
b/Source/cmRulePlaceholderExpander.cxx
index 796c975..601c3b4 100644
--- a/Source/cmRulePlaceholderExpander.cxx
+++ b/Source/cmRulePlaceholderExpander.cxx
@@ -204,8 +204,8 @@ std::string cmRulePlaceholderExpander::ExpandRuleVariable(
 this->Compilers.find(variable);
 
   if (compIt != this->Compilers.end()) {
-std::string ret =
-  this->VariableMappings["CMAKE_" + compIt->second + "_COMPILER"];
+std::string ret = outputConverter->ConvertToOutputForExisting(
+  this->VariableMappings["CMAKE_" + compIt->second + "_COMPILER"]);
 std::string const& compilerArg1 =
   this->VariableMappings[compIt->first + "_COMPILER_ARG1"];
 std::string const& compilerTarget =

---

Summary of changes:
 Source/cmRulePlaceholderExpander.cxx |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-382-g885c6f5

[Stephen Kelly]

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, next has been updated
   via  885c6f5f348a45174cf5e3a799dc8c0f13c37e67 (commit)
   via  ca40503553b08255ae8a67168ee840b9e7487011 (commit)
   via  8bb3d57e7eaa89fb394e33aa29849ee559f29915 (commit)
   via  0cd57caf76abd5560cf09b12c4e894e505980948 (commit)
   via  fd5440694f9dd2d9d1d70d6bcd58a928c8d2e912 (commit)
   via  adee2f4b870ad5aa27437feaf7360ae984afcf27 (commit)
   via  3855acab5f925de761e384007592f54b471eeacd (commit)
   via  331e584c686e3a20708287d807f18a60d64568b0 (commit)
   via  76624fb8470bdc63b3844f84edc3c941bc524f41 (commit)
   via  5e5c1c9224b7b10df29732ab16d7fbc052faba40 (commit)
   via  881c15b360a11f4951ba185e54fbaf8ec028b237 (commit)
   via  7c4ce8062620e6d1375316a5c8966690c475fc2a (commit)
   via  beac5cbd01a48e0d53114ee0156f79108a6ab6ac (commit)
   via  b2fa025ce3d264d9f3313a83ef77a0ded398d07f (commit)
   via  4bc4312ca064a82b3ac157ef0b67235e5cb02afc (commit)
   via  d7f6a6164e7775eeabec0aa5d66c81a365b3d1f1 (commit)
  from  e5c68d04f4eb28ab4f967fe1f127be6b28c0ec92 (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=885c6f5f348a45174cf5e3a799dc8c0f13c37e67
commit 885c6f5f348a45174cf5e3a799dc8c0f13c37e67
Merge: e5c68d0 ca40503
Author: Stephen Kelly 
AuthorDate: Mon Oct 10 17:23:44 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Oct 10 17:23:44 2016 -0400

Merge topic 'extract-cmRulePlaceholderExpander' into next

ca405035 cmRulePlaceholderExpander: Port clients to direct-use
8bb3d57e cmRulePlaceholderExpander: Extract from cmLocalGenerator
0cd57caf cmLocalGenerator: Use strings instead of a Target in rule 
replacement
fd544069 cmLocalGenerator: Use a converter in rule replacement API
adee2f4b cmLocalGenerator: Store variable replacements as state
3855acab cmLocalGenerator: Merge loops which populate mapping
331e584c cmLocalGenerator: Populate variable mapping for all replacements
76624fb8 cmLocalGenerator: Extract compiler option replacement from loop
5e5c1c92 cmLocalGenerator: Populate a container of mappings for replacements
881c15b3 cmLocalGenerator: Move compiler option handling to be more direct
7c4ce806 cmLocalGenerator: Move variable to where it can be used easily
beac5cbd cmLocalGenerator: Use the language from the compiler container
b2fa025c cmLocalGenerator: Introduce a container of compiler names
4bc4312c cmLocalGenerator: Simplify loop with range algorithm
d7f6a616 cmLocalGenerator: Remove the launcher from RuleVariables

diff --cc Source/cmMakefileLibraryTargetGenerator.cxx
index 8a621ea,9f5f0c1..cb8b5e8
--- a/Source/cmMakefileLibraryTargetGenerator.cxx
+++ b/Source/cmMakefileLibraryTargetGenerator.cxx
@@@ -595,10 -609,25 +597,20 @@@ void cmMakefileLibraryTargetGenerator::
  this->LocalGenerator->AddArchitectureFlags(
langFlags, this->GeneratorTarget, linkLanguage, this->ConfigName);
  
 -// remove any language flags that might not work with the
 -// particular os
 -if (forbiddenFlagVar) {
 -  this->RemoveForbiddenFlags(forbiddenFlagVar, linkLanguage, langFlags);
 -}
  vars.LanguageCompileFlags = langFlags.c_str();
  
+ std::string launcher;
+ const char* val = this->LocalGenerator->GetRuleLauncher(
+   this->GeneratorTarget, "RULE_LAUNCH_LINK");
+ if (val && *val) {
+   launcher = val;
+   launcher += " ";
+ }
+ 
+ CM_AUTO_PTR rulePlaceholderExpander(
+   this->LocalGenerator->CreateRulePlaceholderExpander());
  // Construct the main link rule and expand placeholders.
- this->LocalGenerator->TargetImplib = targetOutPathImport;
+ rulePlaceholderExpander->SetTargetImpLib(targetOutPathImport);
  if (useArchiveRules) {
// Construct the individual object list strings.
std::vector object_strings;

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ca40503553b08255ae8a67168ee840b9e7487011
commit ca40503553b08255ae8a67168ee840b9e7487011
Author: Stephen Kelly 
AuthorDate: Sun Oct 9 10:34:50 2016 +0200
Commit: Stephen Kelly 
CommitDate: Mon Oct 10 21:58:50 2016 +0200

cmRulePlaceholderExpander: Port clients to direct-use

Add a factory function to cmLocalGenerator so that variableMappings can
be provided from it, and so that Ninja can always have a hard-coded
TargetImpLib.

diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index 615168d..1c3a97d 100644
--- a/Source/cmLocalGenerator.cxx
+++ 

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-366-ge5c68d0

[Brad King]

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, next has been updated
   via  e5c68d04f4eb28ab4f967fe1f127be6b28c0ec92 (commit)
   via  d9190f3308fb67f01f061038a06006af73a77da1 (commit)
  from  6cb01ac244b6476c2677cf2b2114e9044886c747 (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=e5c68d04f4eb28ab4f967fe1f127be6b28c0ec92
commit e5c68d04f4eb28ab4f967fe1f127be6b28c0ec92
Merge: 6cb01ac d9190f3
Author: Brad King 
AuthorDate: Mon Oct 10 15:50:27 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Oct 10 15:50:27 2016 -0400

Merge topic 'FindProtobuf-debug-suffix' into next

d9190f33 FindProtobuf: Search for debug library named with `d` suffix


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d9190f3308fb67f01f061038a06006af73a77da1
commit d9190f3308fb67f01f061038a06006af73a77da1
Author: Adam Martin 
AuthorDate: Mon Oct 10 14:17:10 2016 -0500
Commit: Brad King 
CommitDate: Mon Oct 10 15:44:21 2016 -0400

FindProtobuf: Search for debug library named with `d` suffix

Protobuf now provides a CMake-based build system that optionally adds a
suffix to the debug library name [1].  Update our `find_library` call to
consider names with the default value for this suffix, `d`.

[1] 
https://github.com/google/protobuf/blob/431cee60/cmake/libprotoc.cmake#L107

diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake
index 14e392a..3ffd5a7 100644
--- a/Modules/FindProtobuf.cmake
+++ b/Modules/FindProtobuf.cmake
@@ -264,7 +264,7 @@ function(_protobuf_find_libraries name filename)
 mark_as_advanced(${name}_LIBRARY_RELEASE)
 
 find_library(${name}_LIBRARY_DEBUG
-  NAMES ${filename}
+  NAMES ${filename}d ${filename}
   PATHS ${Protobuf_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug)
 mark_as_advanced(${name}_LIBRARY_DEBUG)
 

---

Summary of changes:
 Modules/FindProtobuf.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-364-g6cb01ac

[Brad King]

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, next has been updated
   via  6cb01ac244b6476c2677cf2b2114e9044886c747 (commit)
   via  656ebaca3be50e92edca3d9628b784f5ff1e6a99 (commit)
  from  275217f7c9a7b0252643b50f0431001802499daa (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=6cb01ac244b6476c2677cf2b2114e9044886c747
commit 6cb01ac244b6476c2677cf2b2114e9044886c747
Merge: 275217f 656ebac
Author: Brad King 
AuthorDate: Mon Oct 10 14:55:52 2016 -0400
Commit: Brad King 
CommitDate: Mon Oct 10 14:55:52 2016 -0400

Merge branch 'master' into next


---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.7.0-rc1-164-g656ebac

[Brad King]

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  656ebaca3be50e92edca3d9628b784f5ff1e6a99 (commit)
   via  4134030434ea88024ef46f9f00b19513fc3cec4c (commit)
   via  f03d446e967af91460ff31eb52d840983b3d8cec (commit)
   via  3444105f9fe4fcee390c8d616e1a211a078a630b (commit)
   via  77c4202edc242c96087295585a85a20700bdb26f (commit)
   via  09b6cc66b09b9689ca01faee5e33ef101b46f972 (commit)
   via  0c978063259fb013856b617d680cebcdee51ab1a (commit)
   via  0152a01f11fc46f645fd765cc7b1be76cc07b52a (commit)
   via  011e6870e4a7f19476c162a8c011fd018d9a7e9c (commit)
   via  cbca80f3516d7e5b2def6105a1b26b44bad7b6fe (commit)
   via  d48f69d0f5f265d1c091a614098cae3ff4325fbe (commit)
   via  ff8e321c6ade784b3f1b3b19a7783788872e44a9 (commit)
   via  80f57e67eefc905a726f2f35bd1672a188ea4c99 (commit)
   via  7ef834682547df5e0ccdcd503558dcbf1206a638 (commit)
   via  69295812065a5d07c07347add2fdcf8f36f993ba (commit)
   via  5b361fdda0f2808f0368b746a880981ebda0ade0 (commit)
   via  2e5d1990f382aa42e8a0ad34117ee1e5a9187153 (commit)
   via  b3701f9a5213f2ff5b2bc197e9af5d1f2ff68a9c (commit)
  from  06b71ff9fb41369e6dce0c2b9760d2d546d47dec (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=656ebaca3be50e92edca3d9628b784f5ff1e6a99
commit 656ebaca3be50e92edca3d9628b784f5ff1e6a99
Merge: 06b71ff 4134030
Author: Brad King 
AuthorDate: Mon Oct 10 14:55:28 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Oct 10 14:55:28 2016 -0400

Merge topic 'extract-cmLinkLineComputer'

41340304 cmLinkLineComputer: Extract link libraries computation from 
cmLocalGenerator
f03d446e cmLinkLineComputer: Move FrameworkPath computation from 
cmLocalGenerator
3444105f cmLocalGenerator: Inline last use of local variable
77c4202e cmLinkLineComputer: Move RPath computation from cmLocalGenerator
09b6cc66 cmLinkLineComputer: Move LinkPath computation from cmLocalGenerator
0c978063 cmLinkLineComputer: Move ComputeLinkLibs from cmLocalGenerator
0152a01f cmLocalGenerator: Move variable to where it is used
011e6870 cmLocalGenerator: Use a std::string instead of char*
cbca80f3 cmLocalGenerator: Move stringstream to where it is used
d48f69d0 cmLocalGenerator: Move flag determination up in the function
ff8e321c cmLocalGenerator: Separate stdlib content from library stream
80f57e67 cmLocalGenerator: Separate rpath content from library stream
7ef83468 cmLocalGenerator: Pass link library info to OutputLinkLibraries
69295812 Makefiles: Port CreateLinkLibs to cmLinkLineComputer
5b361fdd cmLinkLineComputer: Extract from cmLocalGenerator
2e5d1990 Ninja: Constify
...


---

Summary of changes:
 Source/CMakeLists.txt  |6 +
 Source/cmCommonTargetGenerator.cxx |6 +-
 Source/cmCommonTargetGenerator.h   |4 +-
 Source/cmGhsMultiTargetGenerator.cxx   |   11 +-
 Source/cmGlobalGenerator.cxx   |   14 ++
 Source/cmGlobalGenerator.h |8 ++
 Source/cmGlobalNinjaGenerator.cxx  |   15 +-
 Source/cmGlobalNinjaGenerator.h|8 +-
 Source/cmLinkLineComputer.cxx  |  179 
 Source/cmLinkLineComputer.h|   50 +++
 Source/cmLocalGenerator.cxx|  167 +-
 Source/cmLocalGenerator.h  |   17 +--
 Source/cmLocalNinjaGenerator.cxx   |6 -
 Source/cmLocalNinjaGenerator.h |2 -
 Source/cmMSVC60LinkLineComputer.cxx|   36 +
 Source/cmMSVC60LinkLineComputer.h  |   19 +++
 Source/cmMakefileExecutableTargetGenerator.cxx |   22 ++-
 Source/cmMakefileLibraryTargetGenerator.cxx|   30 +++-
 Source/cmMakefileTargetGenerator.cxx   |   24 +++-
 Source/cmMakefileTargetGenerator.h |   10 +-
 Source/cmNinjaLinkLineComputer.cxx |   19 +++
 Source/cmNinjaLinkLineComputer.h   |   26 
 Source/cmNinjaNormalTargetGenerator.cxx|   15 +-
 Source/cmServerProtocol.cxx|7 +-
 Source/cmake.cxx   |7 +-
 bootstrap  |2 +
 26 files changed, 527 insertions(+), 183 deletions(-)
 create mode 100644 Source/cmLinkLineComputer.cxx
 create mode 100644 Source/cmLinkLineComputer.h
 create mode 100644 

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-362-g275217f

[Brad King]

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, next has been updated
   via  275217f7c9a7b0252643b50f0431001802499daa (commit)
   via  a3c98cb30edba8ba19bc05d4e08fd344f3440f32 (commit)
  from  f62d2c869f7ebbb418bde71bff2ecbfc7a3993b2 (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=275217f7c9a7b0252643b50f0431001802499daa
commit 275217f7c9a7b0252643b50f0431001802499daa
Merge: f62d2c8 a3c98cb
Author: Brad King 
AuthorDate: Mon Oct 10 14:49:34 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Oct 10 14:49:34 2016 -0400

Merge topic 'ExternalProject-fix-CMAKE_CACHE_ARGS-list' into next

a3c98cb3 ExternalProject: Fix regression in passing list to CMAKE_CACHE_ARGS


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3c98cb30edba8ba19bc05d4e08fd344f3440f32
commit a3c98cb30edba8ba19bc05d4e08fd344f3440f32
Author: Max Smolens 
AuthorDate: Mon Oct 10 11:39:57 2016 -0400
Commit: Brad King 
CommitDate: Mon Oct 10 14:40:12 2016 -0400

ExternalProject: Fix regression in passing list to CMAKE_CACHE_ARGS

Fix passing a list to the CMAKE_CACHE_ARGS and CMAKE_CACHE_DEFAULT_ARGS
options of ExternalProject_Add.

Following commit v3.7.0-rc1~273^2~1 (prefer list(APPEND) over
string(APPEND) where appropriate, 2016-08-08), the semicolon list
separator after the first list element was missing in the generated
cache.

diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index bbd..4ba8537 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -1160,7 +1160,7 @@ function(_ep_command_line_to_initial_cache var args force)
   endif()
 else()
   # Assume this is a list to append to the last var
-  list(APPEND accumulator "${line}")
+  string(APPEND accumulator ";${line}")
 endif()
   endforeach()
   # Catch the final line of the args
diff --git a/Tests/RunCMake/ExternalProject/CMAKE_CACHE_ARGS-check.cmake 
b/Tests/RunCMake/ExternalProject/CMAKE_CACHE_ARGS-check.cmake
index c350a63..cb48be7 100644
--- a/Tests/RunCMake/ExternalProject/CMAKE_CACHE_ARGS-check.cmake
+++ b/Tests/RunCMake/ExternalProject/CMAKE_CACHE_ARGS-check.cmake
@@ -15,3 +15,12 @@ if(NOT "${CMAKE_MATCH_0}" MATCHES FORCE)
   set(RunCMake_TEST_FAILED "Expected forced FOO argument")
   return()
 endif()
+
+if(NOT "${_cache}" MATCHES "set\\(TEST_LIST \"A;B;C\".+\\)")
+  set(RunCMake_TEST_FAILED "Cannot find TEST_LIST argument in cache")
+  return()
+endif()
+if(NOT "${CMAKE_MATCH_0}" MATCHES FORCE)
+  set(RunCMake_TEST_FAILED "Expected forced TEST_LIST argument")
+  return()
+endif()
diff --git a/Tests/RunCMake/ExternalProject/CMAKE_CACHE_ARGS.cmake 
b/Tests/RunCMake/ExternalProject/CMAKE_CACHE_ARGS.cmake
index 62b1640..1f76fd0 100644
--- a/Tests/RunCMake/ExternalProject/CMAKE_CACHE_ARGS.cmake
+++ b/Tests/RunCMake/ExternalProject/CMAKE_CACHE_ARGS.cmake
@@ -5,4 +5,6 @@ include(ExternalProject)
 
 ExternalProject_Add(FOO TMP_DIR "${CMAKE_CURRENT_BINARY_DIR}/tmp"
 DOWNLOAD_COMMAND ""
-CMAKE_CACHE_ARGS "-DFOO:STRING=$<1:BAR>$<0:BAD>")
+CMAKE_CACHE_ARGS
+"-DFOO:STRING=$<1:BAR>$<0:BAD>"
+"-DTEST_LIST:STRING=A;B;C")
diff --git 
a/Tests/RunCMake/ExternalProject/CMAKE_CACHE_DEFAULT_ARGS-check.cmake 
b/Tests/RunCMake/ExternalProject/CMAKE_CACHE_DEFAULT_ARGS-check.cmake
index aeee11f..c84932d 100644
--- a/Tests/RunCMake/ExternalProject/CMAKE_CACHE_DEFAULT_ARGS-check.cmake
+++ b/Tests/RunCMake/ExternalProject/CMAKE_CACHE_DEFAULT_ARGS-check.cmake
@@ -15,3 +15,12 @@ if("${CMAKE_MATCH_0}" MATCHES FORCE)
   set(RunCMake_TEST_FAILED "Expected not forced FOO argument")
   return()
 endif()
+
+if(NOT "${_cache}" MATCHES "set\\(TEST_LIST \"A;B;C\".+\\)")
+  set(RunCMake_TEST_FAILED "Cannot find TEST_LIST argument in cache")
+  return()
+endif()
+if("${CMAKE_MATCH_0}" MATCHES FORCE)
+  set(RunCMake_TEST_FAILED "Expected not forced TEST_LIST argument")
+  return()
+endif()
diff --git a/Tests/RunCMake/ExternalProject/CMAKE_CACHE_DEFAULT_ARGS.cmake 
b/Tests/RunCMake/ExternalProject/CMAKE_CACHE_DEFAULT_ARGS.cmake
index 3a83dbe..1b619c8 100644
--- a/Tests/RunCMake/ExternalProject/CMAKE_CACHE_DEFAULT_ARGS.cmake
+++ b/Tests/RunCMake/ExternalProject/CMAKE_CACHE_DEFAULT_ARGS.cmake
@@ -5,4 +5,6 @@ include(ExternalProject)
 
 ExternalProject_Add(FOO TMP_DIR "${CMAKE_CURRENT_BINARY_DIR}/tmp"
 DOWNLOAD_COMMAND ""
-

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-360-gf62d2c8

[Stephen Kelly]

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, next has been updated
   via  f62d2c869f7ebbb418bde71bff2ecbfc7a3993b2 (commit)
   via  4134030434ea88024ef46f9f00b19513fc3cec4c (commit)
   via  f03d446e967af91460ff31eb52d840983b3d8cec (commit)
   via  3444105f9fe4fcee390c8d616e1a211a078a630b (commit)
   via  77c4202edc242c96087295585a85a20700bdb26f (commit)
   via  09b6cc66b09b9689ca01faee5e33ef101b46f972 (commit)
   via  0c978063259fb013856b617d680cebcdee51ab1a (commit)
   via  0152a01f11fc46f645fd765cc7b1be76cc07b52a (commit)
   via  011e6870e4a7f19476c162a8c011fd018d9a7e9c (commit)
   via  cbca80f3516d7e5b2def6105a1b26b44bad7b6fe (commit)
   via  d48f69d0f5f265d1c091a614098cae3ff4325fbe (commit)
   via  ff8e321c6ade784b3f1b3b19a7783788872e44a9 (commit)
   via  80f57e67eefc905a726f2f35bd1672a188ea4c99 (commit)
   via  7ef834682547df5e0ccdcd503558dcbf1206a638 (commit)
   via  69295812065a5d07c07347add2fdcf8f36f993ba (commit)
   via  5b361fdda0f2808f0368b746a880981ebda0ade0 (commit)
   via  2e5d1990f382aa42e8a0ad34117ee1e5a9187153 (commit)
   via  b3701f9a5213f2ff5b2bc197e9af5d1f2ff68a9c (commit)
  from  dd75faf01aecc93c32cbc5941d29033e33af0521 (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=f62d2c869f7ebbb418bde71bff2ecbfc7a3993b2
commit f62d2c869f7ebbb418bde71bff2ecbfc7a3993b2
Merge: dd75faf 4134030
Author: Stephen Kelly 
AuthorDate: Mon Oct 10 14:44:12 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Oct 10 14:44:12 2016 -0400

Merge topic 'extract-cmLinkLineComputer' into next

41340304 cmLinkLineComputer: Extract link libraries computation from 
cmLocalGenerator
f03d446e cmLinkLineComputer: Move FrameworkPath computation from 
cmLocalGenerator
3444105f cmLocalGenerator: Inline last use of local variable
77c4202e cmLinkLineComputer: Move RPath computation from cmLocalGenerator
09b6cc66 cmLinkLineComputer: Move LinkPath computation from cmLocalGenerator
0c978063 cmLinkLineComputer: Move ComputeLinkLibs from cmLocalGenerator
0152a01f cmLocalGenerator: Move variable to where it is used
011e6870 cmLocalGenerator: Use a std::string instead of char*
cbca80f3 cmLocalGenerator: Move stringstream to where it is used
d48f69d0 cmLocalGenerator: Move flag determination up in the function
ff8e321c cmLocalGenerator: Separate stdlib content from library stream
80f57e67 cmLocalGenerator: Separate rpath content from library stream
7ef83468 cmLocalGenerator: Pass link library info to OutputLinkLibraries
69295812 Makefiles: Port CreateLinkLibs to cmLinkLineComputer
5b361fdd cmLinkLineComputer: Extract from cmLocalGenerator
2e5d1990 Ninja: Constify
...


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4134030434ea88024ef46f9f00b19513fc3cec4c
commit 4134030434ea88024ef46f9f00b19513fc3cec4c
Author: Stephen Kelly 
AuthorDate: Sat Oct 8 12:21:39 2016 +0200
Commit: Stephen Kelly 
CommitDate: Mon Oct 10 20:38:59 2016 +0200

cmLinkLineComputer: Extract link libraries computation from cmLocalGenerator

Hide some methods which no longer need to be public.

diff --git a/Source/cmLinkLineComputer.cxx b/Source/cmLinkLineComputer.cxx
index 41096ef..24f3578 100644
--- a/Source/cmLinkLineComputer.cxx
+++ b/Source/cmLinkLineComputer.cxx
@@ -152,3 +152,28 @@ std::string cmLinkLineComputer::ComputeFrameworkPath(
   }
   return frameworkPath;
 }
+
+std::string cmLinkLineComputer::ComputeLinkLibraries(
+  cmComputeLinkInformation& cli, std::string const& stdLibString)
+{
+  std::ostringstream fout;
+  fout << this->ComputeRPath(cli);
+
+  // Write the library flags to the build rule.
+  fout << this->ComputeLinkLibs(cli);
+
+  // Add the linker runtime search path if any.
+  std::string rpath_link = cli.GetRPathLinkString();
+  if (!cli.GetRPathLinkFlag().empty() && !rpath_link.empty()) {
+fout << cli.GetRPathLinkFlag();
+fout << this->OutputConverter->EscapeForShell(rpath_link,
+  !this->ForResponse);
+fout << " ";
+  }
+
+  if (!stdLibString.empty()) {
+fout << stdLibString << " ";
+  }
+
+  return fout.str();
+}
diff --git a/Source/cmLinkLineComputer.h b/Source/cmLinkLineComputer.h
index f72368a..1fb9b24 100644
--- a/Source/cmLinkLineComputer.h
+++ b/Source/cmLinkLineComputer.h
@@ -22,18 +22,20 @@ public:
 
   virtual std::string ConvertToLinkReference(std::string const& input) const;
 
-  std::string ComputeLinkLibs(cmComputeLinkInformation& 

Re: [cmake-developers] FastBuild Generator

[Brad King]

On 10/10/2016 09:39 AM, Charles Huet wrote:
> * the test CMake.CheckSourceTree does not work with Fastbuild,
>   but I could not get it to work with Ninja either, maybe I
>   have an environment problem ?

It works with Ninja for me.  Are you building CMake out-of-source?

> * the test SimpleInstall requires the build tool to be able to
>   run multiple instances in the same hierarchy, which Fastbuild
>   does not support.

I don't understand what you mean.

> * It seems SimpleInstall-Stage2 depends upon SimpleInstall,
>   is this right ?

Yes.

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMake doesn't detect Microsoft Build Tools 2015 on Windows 10

[Gilles Khouzam via CMake]

Please open a bug, I can take a look at it.

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Eduard Wirch
Sent: Monday, October 10, 2016 02:41
To: cmake@cmake.org
Subject: [CMake] CMake doesn't detect Microsoft Build Tools 2015 on Windows 10

Hi

I've installed build tools from here: 
http://landinghub.visualstudio.com/visual-cpp-build-tools
But CMake will automatically detect (and choose) Visual Studio 8 (installed 
here as well) instead.

Looking into the source:

const std::string vsregBase =
  "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\";
std::vector vsVerions;
vsVerions.push_back("VisualStudio\\");
vsVerions.push_back("VCExpress\\");
vsVerions.push_back("WDExpress\\");
struct VSRegistryEntryName
{
  const char* MSVersion;
  const char* GeneratorName;
};
VSRegistryEntryName version[] = {
  /* clang-format needs this comment to break after the opening brace */
  { "7.1", "Visual Studio 7 .NET 2003" },
  { "8.0", "Visual Studio 8 2005" },
  { "9.0", "Visual Studio 9 2008" },
  { "10.0", "Visual Studio 10 2010" },
  { "11.0", "Visual Studio 11 2012" },
  { "12.0", "Visual Studio 12 2013" },
  { "14.0", "Visual Studio 14 2015" },
  { "15.0", "Visual Studio 15" },
  { 0, 0 }
};
for (int i = 0; version[i].MSVersion != 0; i++) {
  for (size_t b = 0; b < vsVerions.size(); b++) {
std::string reg = vsregBase + vsVerions[b] + version[i].MSVersion;
reg += ";InstallDir]";
cmSystemTools::ExpandRegistryValues(reg, cmSystemTools::KeyWOW64_32);
if (!(reg == "/registry")) {
  installedCompiler = version[i].GeneratorName;
  break;
}
  }
}

CMake will look for 
'HKLM\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\InstallDir'. This key is 
not present indeed. When specified explicitly:
cmake . -G "Visual Studio 14 2015"
CMake will correctly detect the compiler and build without problems.

These keys might be helpful when looking for Build Tools:


[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\Setup\VC]
"ProductDir"="C:\\Program Files (x86)\\Microsoft Visual 
Studio 14.0\\VC\\"


[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\Setup\SSDT]
"InstallDir"="C:\\Program Files (x86)\\Microsoft Visual 
Studio 14.0\\"
"VersionNumber"="14.0.50616.0"

Am I missing something or is this a bug which should be reported to issue 
tracker?

Cheers,
Eduard
-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-342-gdd75faf

[Brad King]

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, next has been updated
   via  dd75faf01aecc93c32cbc5941d29033e33af0521 (commit)
   via  b1d67ae8a5a1334bfeaf802c55d517d8eaa0dbf9 (commit)
  from  1b79da2c9939c0674970d36ca282f0e4f62fa8c5 (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=dd75faf01aecc93c32cbc5941d29033e33af0521
commit dd75faf01aecc93c32cbc5941d29033e33af0521
Merge: 1b79da2 b1d67ae
Author: Brad King 
AuthorDate: Mon Oct 10 12:59:16 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Oct 10 12:59:16 2016 -0400

Merge topic 'vs15-separate-flag-table' into next

b1d67ae8 VS: Split flag table between v140 and v141 toolsets


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b1d67ae8a5a1334bfeaf802c55d517d8eaa0dbf9
commit b1d67ae8a5a1334bfeaf802c55d517d8eaa0dbf9
Author: Brad King 
AuthorDate: Mon Oct 10 11:12:36 2016 -0400
Commit: Brad King 
CommitDate: Mon Oct 10 11:43:39 2016 -0400

VS: Split flag table between v140 and v141 toolsets

In commit v3.7.0-rc1~156^2~1 (VS: Update v140 flag tables from VS 15
MSBuild files, 2016-09-02) we extended the v140 flag table with values
from the v141 toolset that comes with VS 15.  However, the v140 toolset
that comes with VS 14 does not have all of these entries and so the
flags just need to be passed without special mapping.  In order to
support both toolsets, split our CL flag table into separate copies for
each version and switch off the toolset name.

Closes: #16352

diff --git a/Source/cmVS14CLFlagTable.h b/Source/cmVS140CLFlagTable.h
similarity index 95%
copy from Source/cmVS14CLFlagTable.h
copy to Source/cmVS140CLFlagTable.h
index c48db68..317cc18 100644
--- a/Source/cmVS14CLFlagTable.h
+++ b/Source/cmVS140CLFlagTable.h
@@ -1,4 +1,4 @@
-static cmVS7FlagTable cmVS14CLFlagTable[] = {
+static cmVS7FlagTable cmVS140CLFlagTable[] = {
 
   // Enum Properties
   { "DebugInformationFormat", "", "None", "None", 0 },
@@ -60,9 +60,6 @@ static cmVS7FlagTable cmVS14CLFlagTable[] = {
   { "BufferSecurityCheck", "GS-", "Disable Security Check", "false", 0 },
   { "BufferSecurityCheck", "GS", "Enable Security Check", "true", 0 },
 
-  { "ControlFlowGuard", "guard:cf", "Yes", "Guard", 0 },
-  { "ControlFlowGuard", "", "No", "false", 0 },
-
   { "EnableEnhancedInstructionSet", "arch:SSE", "Streaming SIMD Extensions",
 "StreamingSIMDExtensions", 0 },
   { "EnableEnhancedInstructionSet", "arch:SSE2", "Streaming SIMD Extensions 2",
@@ -79,10 +76,6 @@ static cmVS7FlagTable cmVS14CLFlagTable[] = {
   { "FloatingPointModel", "fp:strict", "Strict", "Strict", 0 },
   { "FloatingPointModel", "fp:fast", "Fast", "Fast", 0 },
 
-  { "LanguageStandard", "std:c++14", "ISO C++14 Standard", "stdcpp14", 0 },
-  { "LanguageStandard", "std:c++latest", "ISO C++ Latest Draft Standard",
-"stdcpplatest", 0 },
-
   { "PrecompiledHeader", "Yc", "Create", "Create",
 cmVS7FlagTable::UserValueIgnored | cmVS7FlagTable::Continue },
   { "PrecompiledHeader", "Yu", "Use", "Use",
@@ -171,9 +164,6 @@ static cmVS7FlagTable cmVS14CLFlagTable[] = {
   { "TreatWChar_tAsBuiltInType", "Zc:wchar_t", "", "true", 0 },
   { "ForceConformanceInForLoopScope", "Zc:forScope-", "", "false", 0 },
   { "ForceConformanceInForLoopScope", "Zc:forScope", "", "true", 0 },
-  { "RemoveUnreferencedCodeData", "Zc:inline", "", "true", 0 },
-  { "EnforceTypeConversionRules", "Zc:rvalueCast-", "", "false", 0 },
-  { "EnforceTypeConversionRules", "Zc:rvalueCast", "", "true", 0 },
   { "RuntimeTypeInfo", "GR-", "", "false", 0 },
   { "RuntimeTypeInfo", "GR", "", "true", 0 },
   { "OpenMPSupport", "openmp-", "", "false", 0 },
@@ -225,8 +215,6 @@ static cmVS7FlagTable cmVS14CLFlagTable[] = {
 "", cmVS7FlagTable::UserValue | cmVS7FlagTable::SemicolonAppendable },
 
   // String Properties
-  { "WarningVersion", "Wv:", "Warning Version", "",
-cmVS7FlagTable::UserValue },
   // Skip [TrackerLogDirectory] - no command line Switch.
   { "PreprocessOutputPath", "Fi", "Preprocess Output Path", "",
 cmVS7FlagTable::UserValue },
diff --git a/Source/cmVS14CLFlagTable.h b/Source/cmVS141CLFlagTable.h
similarity index 99%
rename from Source/cmVS14CLFlagTable.h
rename to Source/cmVS141CLFlagTable.h
index c48db68..895b3e8 100644
--- a/Source/cmVS14CLFlagTable.h
+++ b/Source/cmVS141CLFlagTable.h
@@ -1,4 +1,4 @@
-static cmVS7FlagTable cmVS14CLFlagTable[] = {
+static cmVS7FlagTable cmVS141CLFlagTable[] = {
 
   // Enum Properties
   { "DebugInformationFormat", "", "None", "None", 0 },
diff 

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-340-g1b79da2

[Brad King]

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, next has been updated
   via  1b79da2c9939c0674970d36ca282f0e4f62fa8c5 (commit)
   via  06b71ff9fb41369e6dce0c2b9760d2d546d47dec (commit)
   via  9f240cff8ad14832dbc5472917b3b2e3fe813e46 (commit)
   via  5d8da06d60138c18eb68fab01b9b6e736ecd4914 (commit)
   via  a033f8671272c382ba55c23f1269439cc4db4a97 (commit)
   via  111d90465f00559c808b7a02944f890af6c0fe89 (commit)
   via  d231f3b738b31ebad075c49abcef972c268ba9d0 (commit)
   via  fbc1a30b87f9af2f798e1f2dc61e94089a99e213 (commit)
   via  5c17a5b87984b9bcb7e6f20445b0efdcd124 (commit)
   via  dcf9729eb9a3647fc3c9cd5f2e04a5419420fb61 (commit)
  from  92810dc819dc45bad1a7aff6bb10b82c9d2451f7 (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=1b79da2c9939c0674970d36ca282f0e4f62fa8c5
commit 1b79da2c9939c0674970d36ca282f0e4f62fa8c5
Merge: 92810dc 06b71ff
Author: Brad King 
AuthorDate: Mon Oct 10 11:31:15 2016 -0400
Commit: Brad King 
CommitDate: Mon Oct 10 11:31:15 2016 -0400

Merge branch 'master' into next


---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, release, updated. v3.7.0-rc1-32-g9f240cf

[Brad King]

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  9f240cff8ad14832dbc5472917b3b2e3fe813e46 (commit)
   via  c22f3cf7153fcf766d0ecc17d72e93bf4209e0b2 (commit)
   via  bf28a3873d633d233991f14e8e4d10c76f410deb (commit)
   via  5d8da06d60138c18eb68fab01b9b6e736ecd4914 (commit)
   via  dda6775c940129d2a38fecd6cf6273f7d97ccca0 (commit)
   via  a033f8671272c382ba55c23f1269439cc4db4a97 (commit)
   via  111d90465f00559c808b7a02944f890af6c0fe89 (commit)
   via  8cdac469d19f486b167006e4d4fcbf2a18c85866 (commit)
   via  2b9dad694a43d850af5fe83dd327fc82db29a012 (commit)
   via  d231f3b738b31ebad075c49abcef972c268ba9d0 (commit)
   via  20e8dcf162b9963c9ff195525bc433df2bc2de2a (commit)
   via  845b98f45b09b399f914d9df3c6a6008d7558b1b (commit)
   via  fbc1a30b87f9af2f798e1f2dc61e94089a99e213 (commit)
   via  80574a38e6cb6ac33630e878d9633f1267b53d2b (commit)
   via  5c17a5b87984b9bcb7e6f20445b0efdcd124 (commit)
   via  0c3a04777cc5fa8bc43b57b789e72630781ef56a (commit)
   via  ebef3632c79491c402991967aab03a9c971cb70d (commit)
   via  f59e87792943904dcb11e16380883e87395d115f (commit)
   via  dcf9729eb9a3647fc3c9cd5f2e04a5419420fb61 (commit)
   via  f53b01ff0fdead346f3f63310d4a7359db269fb4 (commit)
   via  ca50c89e416934a586ad6839b2aaba8e7257cc2e (commit)
  from  aac66d79743b3ad1bae0fd9facc9ac329fa9df53 (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:
 CMakeLists.txt |8 ++-
 Help/variable/CMAKE_CODELITE_USE_TARGETS.rst   |5 +-
 Modules/CPackRPM.cmake |   68 
 Modules/FindProtobuf.cmake |   16 +++--
 Modules/Platform/Android/ndk-stl-c++.cmake |   10 ++-
 Source/cmExportBuildAndroidMKGenerator.cxx |   12 
 Source/cmExtraCodeLiteGenerator.cxx|4 +-
 Source/cmGlobalGenerator.cxx   |   19 ++
 Source/cmGlobalGenerator.h |4 ++
 Source/kwsys/SystemTools.cxx   |   20 +++---
 Tests/RunCMake/Android/android.cxx |3 +
 Tests/RunCMake/Android/common.cmake|6 +-
 Tests/RunCMake/AndroidMK/AndroidMK.cmake   |2 +-
 Tests/RunCMake/AndroidMK/bar.c |3 +
 .../RunCMake/AndroidMK/expectedBuildAndroidMK.txt  |3 +
 .../AndroidMK/expectedInstallAndroidMK.txt |3 +
 16 files changed, 130 insertions(+), 56 deletions(-)
 create mode 100644 Tests/RunCMake/AndroidMK/bar.c


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.7.0-rc1-146-g06b71ff

[Brad King]

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  06b71ff9fb41369e6dce0c2b9760d2d546d47dec (commit)
   via  9f240cff8ad14832dbc5472917b3b2e3fe813e46 (commit)
   via  5d8da06d60138c18eb68fab01b9b6e736ecd4914 (commit)
   via  a033f8671272c382ba55c23f1269439cc4db4a97 (commit)
   via  111d90465f00559c808b7a02944f890af6c0fe89 (commit)
   via  d231f3b738b31ebad075c49abcef972c268ba9d0 (commit)
   via  fbc1a30b87f9af2f798e1f2dc61e94089a99e213 (commit)
   via  5c17a5b87984b9bcb7e6f20445b0efdcd124 (commit)
   via  dcf9729eb9a3647fc3c9cd5f2e04a5419420fb61 (commit)
  from  1e6aaefdeebbf09eaf7fa0e9dbc6a7faa2f9132a (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:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-330-g92810dc

[Brad King]

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, next has been updated
   via  92810dc819dc45bad1a7aff6bb10b82c9d2451f7 (commit)
   via  b6a174d2bcd5d64cff7a54a4744fe2b5811d6f9e (commit)
   via  d0faa58a51114a97f3af6a951b6c4052ca19c9ee (commit)
  from  3826f1c832b071df8bb7163d44ad1981724ad70b (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=92810dc819dc45bad1a7aff6bb10b82c9d2451f7
commit 92810dc819dc45bad1a7aff6bb10b82c9d2451f7
Merge: 3826f1c b6a174d
Author: Brad King 
AuthorDate: Mon Oct 10 10:39:10 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Oct 10 10:39:10 2016 -0400

Merge topic 'remove-obsolete' into next

b6a174d2 Makefiles: Remove query for CMAKE_OBJECT_NAME
d0faa58a Makefiles: Remove forbidden flag logic


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b6a174d2bcd5d64cff7a54a4744fe2b5811d6f9e
commit b6a174d2bcd5d64cff7a54a4744fe2b5811d6f9e
Author: Stephen Kelly 
AuthorDate: Sun Oct 9 10:58:33 2016 +0200
Commit: Stephen Kelly 
CommitDate: Sun Oct 9 10:58:33 2016 +0200

Makefiles: Remove query for CMAKE_OBJECT_NAME

it is not set.

diff --git a/Source/cmMakefileTargetGenerator.cxx 
b/Source/cmMakefileTargetGenerator.cxx
index d256a69..9f5bda9 100644
--- a/Source/cmMakefileTargetGenerator.cxx
+++ b/Source/cmMakefileTargetGenerator.cxx
@@ -1207,9 +1207,7 @@ void cmMakefileTargetGenerator::WriteObjectsVariable(
i != this->ExternalObjects.end(); ++i) {
 object =
   this->LocalGenerator->MaybeConvertToRelativePath(currentBinDir, *i);
-*this->BuildFileStream << " " << lineContinue << "\n"
-   << this->Makefile->GetSafeDefinition(
-"CMAKE_OBJECT_NAME");
+*this->BuildFileStream << " " << lineContinue << "\n";
 *this->BuildFileStream << this->LocalGenerator->ConvertToQuotedOutputPath(
   i->c_str(), useWatcomQuote);
   }

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d0faa58a51114a97f3af6a951b6c4052ca19c9ee
commit d0faa58a51114a97f3af6a951b6c4052ca19c9ee
Author: Stephen Kelly 
AuthorDate: Sun Oct 9 10:58:33 2016 +0200
Commit: Stephen Kelly 
CommitDate: Sun Oct 9 10:58:33 2016 +0200

Makefiles: Remove forbidden flag logic

This might have been needed some day in the past, but not anymore.

diff --git a/Modules/Platform/Darwin.cmake b/Modules/Platform/Darwin.cmake
index bb085ac..c09bac4 100644
--- a/Modules/Platform/Darwin.cmake
+++ b/Modules/Platform/Darwin.cmake
@@ -105,8 +105,6 @@ if("${_CURRENT_OSX_VERSION}" VERSION_LESS "10.5")
   set(CMAKE_LINK_DEPENDENT_LIBRARY_FILES 1)
 endif()
 
-set(CMAKE_C_CREATE_SHARED_LIBRARY_FORBIDDEN_FLAGS -w)
-set(CMAKE_CXX_CREATE_SHARED_LIBRARY_FORBIDDEN_FLAGS -w)
 set(CMAKE_C_CREATE_SHARED_LIBRARY
   "  
  -o   
  ")
 set(CMAKE_CXX_CREATE_SHARED_LIBRARY
diff --git a/Source/cmMakefileLibraryTargetGenerator.cxx 
b/Source/cmMakefileLibraryTargetGenerator.cxx
index 8e25f43..5db5c24 100644
--- a/Source/cmMakefileLibraryTargetGenerator.cxx
+++ b/Source/cmMakefileLibraryTargetGenerator.cxx
@@ -352,18 +352,6 @@ void cmMakefileLibraryTargetGenerator::WriteLibraryRules(
   commands, buildEcho, cmLocalUnixMakefileGenerator3::EchoLink, );
   }
 
-  const char* forbiddenFlagVar = CM_NULLPTR;
-  switch (this->GeneratorTarget->GetType()) {
-case cmState::SHARED_LIBRARY:
-  forbiddenFlagVar = "_CREATE_SHARED_LIBRARY_FORBIDDEN_FLAGS";
-  break;
-case cmState::MODULE_LIBRARY:
-  forbiddenFlagVar = "_CREATE_SHARED_MODULE_FORBIDDEN_FLAGS";
-  break;
-default:
-  break;
-  }
-
   // Clean files associated with this library.
   std::vector libCleanFiles;
   libCleanFiles.push_back(this->LocalGenerator->MaybeConvertToRelativePath(
@@ -585,11 +573,6 @@ void cmMakefileLibraryTargetGenerator::WriteLibraryRules(
 this->LocalGenerator->AddArchitectureFlags(
   langFlags, this->GeneratorTarget, linkLanguage, this->ConfigName);
 
-// remove any language flags that might not work with the
-// particular os
-if (forbiddenFlagVar) {
-  this->RemoveForbiddenFlags(forbiddenFlagVar, linkLanguage, langFlags);
-}
 vars.LanguageCompileFlags = langFlags.c_str();
 
 // Construct the main link rule and expand placeholders.
diff --git a/Source/cmMakefileTargetGenerator.cxx 
b/Source/cmMakefileTargetGenerator.cxx
index 14102ef..d256a69 100644
--- a/Source/cmMakefileTargetGenerator.cxx
+++ b/Source/cmMakefileTargetGenerator.cxx
@@ -1416,52 +1416,6 @@ void 

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-327-g3826f1c

[Brad King]

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, next has been updated
   via  3826f1c832b071df8bb7163d44ad1981724ad70b (commit)
   via  14252b2d864c26a9331421c600744464c9c3c08f (commit)
  from  d3f418e5be2c94933abfccf13e3aea031472c949 (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=3826f1c832b071df8bb7163d44ad1981724ad70b
commit 3826f1c832b071df8bb7163d44ad1981724ad70b
Merge: d3f418e 14252b2
Author: Brad King 
AuthorDate: Mon Oct 10 10:34:21 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Oct 10 10:34:21 2016 -0400

Merge topic 'extract-cmLinkLineComputer' into next

14252b2d Revert topic 'extract-cmLinkLineComputer'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=14252b2d864c26a9331421c600744464c9c3c08f
commit 14252b2d864c26a9331421c600744464c9c3c08f
Author: Brad King 
AuthorDate: Mon Oct 10 10:34:00 2016 -0400
Commit: Brad King 
CommitDate: Mon Oct 10 10:34:00 2016 -0400

Revert topic 'extract-cmLinkLineComputer'

It will have further discussion in its MR.

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index 048667a..e574957 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -300,8 +300,6 @@ set(SRCS
   cmInstallDirectoryGenerator.cxx
   cmLinkedTree.h
   cmLinkItem.h
-  cmLinkLineComputer.cxx
-  cmLinkLineComputer.h
   cmListFileCache.cxx
   cmListFileCache.h
   cmListFileLexer.c
@@ -320,8 +318,6 @@ set(SRCS
   cmMakefileUtilityTargetGenerator.cxx
   cmMessenger.cxx
   cmMessenger.h
-  cmMSVC60LinkLineComputer.cxx
-  cmMSVC60LinkLineComputer.h
   cmOSXBundleGenerator.cxx
   cmOSXBundleGenerator.h
   cmOutputConverter.cxx
@@ -549,8 +545,6 @@ set(SRCS ${SRCS}
   cmNinjaNormalTargetGenerator.h
   cmNinjaUtilityTargetGenerator.cxx
   cmNinjaUtilityTargetGenerator.h
-  cmNinjaLinkLineComputer.cxx
-  cmNinjaLinkLineComputer.h
   )
 
 # Temporary variable for tools targets
diff --git a/Source/cmCommonTargetGenerator.cxx 
b/Source/cmCommonTargetGenerator.cxx
index b995fa1..14ea1a9 100644
--- a/Source/cmCommonTargetGenerator.cxx
+++ b/Source/cmCommonTargetGenerator.cxx
@@ -12,7 +12,6 @@
 #include "cmComputeLinkInformation.h"
 #include "cmGeneratorTarget.h"
 #include "cmGlobalCommonGenerator.h"
-#include "cmLinkLineComputer.h"
 #include "cmLocalCommonGenerator.h"
 #include "cmLocalGenerator.h"
 #include "cmMakefile.h"
@@ -60,8 +59,7 @@ void cmCommonTargetGenerator::AddFeatureFlags(std::string& 
flags,
   }
 }
 
-void cmCommonTargetGenerator::AddModuleDefinitionFlag(
-  cmLinkLineComputer* linkLineComputer, std::string& flags)
+void cmCommonTargetGenerator::AddModuleDefinitionFlag(std::string& flags)
 {
   if (!this->ModuleDefinitionFile) {
 return;
@@ -78,7 +76,7 @@ void cmCommonTargetGenerator::AddModuleDefinitionFlag(
   // vs6's "cl -link" pass it to the linker.
   std::string flag = defFileFlag;
   flag += this->LocalGenerator->ConvertToOutputFormat(
-linkLineComputer->ConvertToLinkReference(
+this->LocalGenerator->ConvertToLinkReference(
   this->ModuleDefinitionFile->GetFullPath()),
 cmOutputConverter::SHELL);
   this->LocalGenerator->AppendFlags(flags, flag);
diff --git a/Source/cmCommonTargetGenerator.h b/Source/cmCommonTargetGenerator.h
index fe27038..707b81e 100644
--- a/Source/cmCommonTargetGenerator.h
+++ b/Source/cmCommonTargetGenerator.h
@@ -16,7 +16,6 @@ class cmGlobalCommonGenerator;
 class cmLocalCommonGenerator;
 class cmMakefile;
 class cmSourceFile;
-class cmLinkLineComputer;
 
 /** \class cmCommonTargetGenerator
  * \brief Common infrastructure for Makefile and Ninja per-target generators
@@ -38,8 +37,7 @@ protected:
   bool GetFeatureAsBool(const std::string& feature);
 
   // Helper to add flag for windows .def file.
-  void AddModuleDefinitionFlag(cmLinkLineComputer* linkLineComputer,
-   std::string& flags);
+  void AddModuleDefinitionFlag(std::string& flags);
 
   cmGeneratorTarget* GeneratorTarget;
   cmMakefile* Makefile;
diff --git a/Source/cmGhsMultiTargetGenerator.cxx 
b/Source/cmGhsMultiTargetGenerator.cxx
index dd8b36f..959dfdb 100644
--- a/Source/cmGhsMultiTargetGenerator.cxx
+++ b/Source/cmGhsMultiTargetGenerator.cxx
@@ -5,7 +5,6 @@
 #include "cmGeneratedFileStream.h"
 #include "cmGeneratorTarget.h"
 #include "cmGlobalGhsMultiGenerator.h"
-#include "cmLinkLineComputer.h"
 #include "cmLocalGhsMultiGenerator.h"
 #include "cmMakefile.h"
 #include "cmSourceFile.h"
@@ -363,15 +362,9 @@ void cmGhsMultiTargetGenerator::WriteTargetLinkLibraries(
   

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-325-gd3f418e

[Brad King]

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, next has been updated
   via  d3f418e5be2c94933abfccf13e3aea031472c949 (commit)
   via  1e6aaefdeebbf09eaf7fa0e9dbc6a7faa2f9132a (commit)
   via  ea533eb71516a92e1528e358ffa374b16864eac6 (commit)
   via  8fe948c54cd0a7a06b5c56e8a40dab945c5a08e7 (commit)
   via  9c7fc00a45b6f0891c95fba707b0e2ce9d2e2dbf (commit)
   via  211e3223a6f96800b5c7187a58715a8e1e081869 (commit)
   via  e8cdbec45e757352580476a329f4998074d1b10a (commit)
   via  d3f1fcf6d19d4f4384861b4f342b632d249e1449 (commit)
   via  19d4f942fe5fe2d84e9fc1f6abe9c237f6dceeec (commit)
   via  ce002921344cceb42801d088ab82fcf8f21964da (commit)
   via  e3c5aed6ae1b0dcdde51f5baea7f150395d21d9f (commit)
   via  785bfae867de0ad18463d618d45b4ae8c2712934 (commit)
  from  479b0e2175da23aa995c19cc03d2abbfae1ea551 (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=d3f418e5be2c94933abfccf13e3aea031472c949
commit d3f418e5be2c94933abfccf13e3aea031472c949
Merge: 479b0e2 1e6aaef
Author: Brad King 
AuthorDate: Mon Oct 10 10:24:00 2016 -0400
Commit: Brad King 
CommitDate: Mon Oct 10 10:24:00 2016 -0400

Merge branch 'master' into next


---

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
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.7.0-rc1-110-g8fe948c

[Brad King]

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  8fe948c54cd0a7a06b5c56e8a40dab945c5a08e7 (commit)
   via  c637e0c53b5b81d6605018bd64ea2769f356662a (commit)
   via  fbc1b75c2692d82f729359b0aeec7ad959662d54 (commit)
   via  3d0e95f64c996d3d54b387f7688f988dd843ac6a (commit)
   via  2a49d86d5dec66f7696bd7063459f504cc336a5e (commit)
   via  b0301db23b12351720993a351fedf081ca0fa444 (commit)
   via  267e02097e90d05a16ffd1aa53fb7910b79aa0ec (commit)
   via  009019f2596de08c488588fd2c67a423f9fe92bf (commit)
   via  378849f41e574e72c577b549dfc2d5333ca8f9b5 (commit)
   via  4a3c49b4698f0e8c20c345770f551142088a3037 (commit)
  from  9c7fc00a45b6f0891c95fba707b0e2ce9d2e2dbf (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=8fe948c54cd0a7a06b5c56e8a40dab945c5a08e7
commit 8fe948c54cd0a7a06b5c56e8a40dab945c5a08e7
Merge: 9c7fc00 c637e0c
Author: Brad King 
AuthorDate: Mon Oct 10 10:23:39 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Oct 10 10:23:39 2016 -0400

Merge topic 'minor-cleanups'

c637e0c5 cmMakefile: Return a string from GetDefineFlags
fbc1b75c Test: Remove condition for CMake version no longer supported
3d0e95f6 cmLocalGenerator: Extract definition retrieval out of loop
2a49d86d Makefiles: Inline only use of method
b0301db2 Makefiles: Make helper class independent of cmLocalGenerator
267e0209 cmMakefile: Remove pointless condition
009019f2 Makefiles: Extract identical code from condition
378849f4 Makefiles: Replace array access with local variable
4a3c49b4 Makefiles: Separate two coupled calls


---

Summary of changes:
 Source/cmGhsMultiTargetGenerator.cxx |2 +-
 Source/cmLocalGenerator.cxx  |5 +--
 Source/cmLocalUnixMakefileGenerator3.cxx |   13 +++
 Source/cmMakefile.cxx|6 ++--
 Source/cmMakefile.h  |2 +-
 Source/cmMakefileTargetGenerator.cxx |   41 +-
 Source/cmMakefileTargetGenerator.h   |1 -
 Tests/FindPackageModeMakefileTest/CMakeLists.txt |   13 ++-
 8 files changed, 39 insertions(+), 44 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.7.0-rc1-100-g9c7fc00

[Brad King]

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  9c7fc00a45b6f0891c95fba707b0e2ce9d2e2dbf (commit)
   via  326d5fa74781d807b9ecc2feed1b433657c3a92b (commit)
   via  7d45db99563c83a1a85722b1ee0f1fe10f8967d3 (commit)
   via  a28b8f95bca8ac99c811fe24cd1e291330a1cd28 (commit)
   via  66c6144cdafcae83fe4c36a4355a67aa69198809 (commit)
  from  211e3223a6f96800b5c7187a58715a8e1e081869 (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=9c7fc00a45b6f0891c95fba707b0e2ce9d2e2dbf
commit 9c7fc00a45b6f0891c95fba707b0e2ce9d2e2dbf
Merge: 211e322 326d5fa
Author: Brad King 
AuthorDate: Mon Oct 10 10:23:36 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Oct 10 10:23:36 2016 -0400

Merge topic 'cmake-cleanup'

326d5fa7 Allow custom built libarchive to use custom built expat.
7d45db99 Don't require liblzma when using system libarchive
a28b8f95 Don't require libbz2 when using system libarchive
66c6144c CMakeCPack: remove obsolete conditions


---

Summary of changes:
 CMakeCPack.cmake |  345 +++---
 CMakeLists.txt   |   83 +++--
 2 files changed, 216 insertions(+), 212 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.7.0-rc1-137-g1e6aaef

[Brad King]

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  1e6aaefdeebbf09eaf7fa0e9dbc6a7faa2f9132a (commit)
   via  a1cfc4fe3deed4d642773d0ae63dd524c3f2eba1 (commit)
   via  4079ba20d9d9c8d15fd28d9440d56c907dda811c (commit)
   via  17ab8e33f005aab3e493ac4535f63b6f229aacab (commit)
   via  7edfcd0e834a4dc8d3da9cada6ad6b9b46dfb4dd (commit)
   via  6c8dc7f1df6d3492d11ad994a35ee2f0b8a4e60b (commit)
   via  1efca9f427a5c537afc034aadf0c29073bfdfa22 (commit)
   via  d9b5f0a301c23c2c0e56ad3fcb696de71c3d6365 (commit)
   via  1c70c6cc09f0f8be087db2aeae5ee6a3f1b47bda (commit)
   via  2b7baed719e4a6eb918ed6f22ee6031a40b7f316 (commit)
   via  7ba954925a876f4c753a4296236bc7d2f18eb0b8 (commit)
   via  6d98b15fc8b9a065325e3683afe94efce17dd162 (commit)
   via  869037ee86d1c0ab757840adf499ea270d4301e1 (commit)
   via  2f6462a634726d9d0ea8d8552454839d67183016 (commit)
   via  148b83a12185d7611ff7576464087430c3f2719c (commit)
   via  4457a9f181663701961dc209740974f48213e6e7 (commit)
   via  4d039c5b46e3cac29ff1d9ce3e768af1bca6b69a (commit)
   via  c8ec8d6a7ec6c176bc14e7026dc755a9be8689cb (commit)
   via  3e8d47d18b4db6b4621ee5e4864dde234ad8a282 (commit)
   via  3b4895fa35e4a96022abd99b07002a7d2ab3a968 (commit)
   via  2232e97a6ed4a338b814d1ba3d62a7ffa9ef6e7f (commit)
   via  9a1d4e4ba170f4ac34c80593bd2fe8e1481a1181 (commit)
   via  8391b3015a82909828b7ada98e76d45aa11b892b (commit)
  from  ea533eb71516a92e1528e358ffa374b16864eac6 (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=1e6aaefdeebbf09eaf7fa0e9dbc6a7faa2f9132a
commit 1e6aaefdeebbf09eaf7fa0e9dbc6a7faa2f9132a
Merge: ea533eb a1cfc4f
Author: Brad King 
AuthorDate: Mon Oct 10 10:23:45 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Oct 10 10:23:45 2016 -0400

Merge topic 'clean-up-link-configuration'

a1cfc4fe cmMakefile: Simplify programmer error to an assert
4079ba20 cmMakefile: Implement LinkLibraries as an internal property
17ab8e33 cmMakefile: Inline method into only remaining caller
7edfcd0e cmMakefile: Inline method into caller
6c8dc7f1 cmake: Simplify find-package mode library addition
1efca9f4 cmMakefile: Remove obsolete parameter
d9b5f0a3 cmTarget: Remove target name from parameter list
1c70c6cc cmMakefile: Use public API to find a target
2b7baed7 cmMakefile: Inline method into only caller
7ba95492 cmMakefile: Use public API to find a target
6d98b15f cmMakefile: Invert if() condition to remove else
869037ee cmMakefile: Remove ALIAS check
2f6462a6 cmMakefile: Collapse two consecutive if()s into one
148b83a1 cmMakefile: DeMorgan-invert condition
4457a9f1 cmMakefile: Return after error and remove else condition
4d039c5b cmMakefile: Invert handling of error condition
...


---

Summary of changes:
 Source/cmCPluginAPI.cxx |   44 -
 Source/cmLinkLibrariesCommand.cxx   |7 +-
 Source/cmMakefile.cxx   |  147 ---
 Source/cmMakefile.h |   16 +---
 Source/cmTarget.cxx |   24 +
 Source/cmTarget.h   |8 +-
 Source/cmTargetLinkLibrariesCommand.cxx |   30 ++-
 Source/cmake.cxx|2 +-
 8 files changed, 134 insertions(+), 144 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.7.0-rc1-95-g211e322

[Brad King]

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  211e3223a6f96800b5c7187a58715a8e1e081869 (commit)
   via  7f90d5e5ccfa862ebd99bd79632cc9351fe2ee19 (commit)
  from  e8cdbec45e757352580476a329f4998074d1b10a (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=211e3223a6f96800b5c7187a58715a8e1e081869
commit 211e3223a6f96800b5c7187a58715a8e1e081869
Merge: e8cdbec 7f90d5e
Author: Brad King 
AuthorDate: Mon Oct 10 10:23:33 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Oct 10 10:23:33 2016 -0400

Merge topic 'test-cpack-improve-failure-messages'

7f90d5e5 Tests: Improve RunCMake.CPack_* failure message formatting


---

Summary of changes:
 Tests/RunCMake/CPack/VerifyResult.cmake |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.7.0-rc1-88-g19d4f94

[Brad King]

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  19d4f942fe5fe2d84e9fc1f6abe9c237f6dceeec (commit)
   via  8cdac469d19f486b167006e4d4fcbf2a18c85866 (commit)
  from  ce002921344cceb42801d088ab82fcf8f21964da (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=19d4f942fe5fe2d84e9fc1f6abe9c237f6dceeec
commit 19d4f942fe5fe2d84e9fc1f6abe9c237f6dceeec
Merge: ce00292 8cdac46
Author: Brad King 
AuthorDate: Mon Oct 10 10:23:24 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Oct 10 10:23:24 2016 -0400

Merge topic 'android-cxxabi'

8cdac469 Android: Fix support for cxxabi.h with libc++


---

Summary of changes:
 Modules/Platform/Android/ndk-stl-c++.cmake |2 ++
 Tests/RunCMake/Android/android.cxx |3 +++
 Tests/RunCMake/Android/common.cmake|2 ++
 3 files changed, 7 insertions(+)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.7.0-rc1-86-gce00292

[Brad King]

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  ce002921344cceb42801d088ab82fcf8f21964da (commit)
   via  2b9dad694a43d850af5fe83dd327fc82db29a012 (commit)
  from  e3c5aed6ae1b0dcdde51f5baea7f150395d21d9f (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=ce002921344cceb42801d088ab82fcf8f21964da
commit ce002921344cceb42801d088ab82fcf8f21964da
Merge: e3c5aed 2b9dad6
Author: Brad King 
AuthorDate: Mon Oct 10 10:23:21 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Oct 10 10:23:21 2016 -0400

Merge topic 'FindProtobuf-fix-subdirs'

2b9dad69 FindProtobuf: Fix protobuf_generate_*() to handle subdirs


---

Summary of changes:
 Modules/FindProtobuf.cmake |   16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.7.0-rc1-93-ge8cdbec

[Brad King]

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  e8cdbec45e757352580476a329f4998074d1b10a (commit)
   via  c22f3cf7153fcf766d0ecc17d72e93bf4209e0b2 (commit)
   via  bf28a3873d633d233991f14e8e4d10c76f410deb (commit)
  from  d3f1fcf6d19d4f4384861b4f342b632d249e1449 (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=e8cdbec45e757352580476a329f4998074d1b10a
commit e8cdbec45e757352580476a329f4998074d1b10a
Merge: d3f1fcf c22f3cf
Author: Brad King 
AuthorDate: Mon Oct 10 10:23:30 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Oct 10 10:23:30 2016 -0400

Merge topic 'update-kwsys'

c22f3cf7 Merge branch 'upstream-KWSys' into update-kwsys
bf28a387 KWSys 2016-10-07 (dfe9b386)


---

Summary of changes:
 Source/kwsys/SystemTools.cxx |   20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.7.0-rc1-90-gd3f1fcf

[Brad King]

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  d3f1fcf6d19d4f4384861b4f342b632d249e1449 (commit)
   via  dda6775c940129d2a38fecd6cf6273f7d97ccca0 (commit)
  from  19d4f942fe5fe2d84e9fc1f6abe9c237f6dceeec (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=d3f1fcf6d19d4f4384861b4f342b632d249e1449
commit d3f1fcf6d19d4f4384861b4f342b632d249e1449
Merge: 19d4f94 dda6775
Author: Brad King 
AuthorDate: Mon Oct 10 10:23:27 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Oct 10 10:23:27 2016 -0400

Merge topic 'android-export-has-cpp'

dda6775c Android: Record use of C++ by static libs in exported Android.mk 
files


---

Summary of changes:
 Source/cmExportBuildAndroidMKGenerator.cxx|   12 
 Tests/RunCMake/AndroidMK/AndroidMK.cmake  |2 +-
 Tests/RunCMake/AndroidMK/bar.c|3 +++
 Tests/RunCMake/AndroidMK/expectedBuildAndroidMK.txt   |3 +++
 Tests/RunCMake/AndroidMK/expectedInstallAndroidMK.txt |3 +++
 5 files changed, 22 insertions(+), 1 deletion(-)
 create mode 100644 Tests/RunCMake/AndroidMK/bar.c


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.7.0-rc1-313-g479b0e2

[Brad King]

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, next has been updated
   via  479b0e2175da23aa995c19cc03d2abbfae1ea551 (commit)
   via  c637e0c53b5b81d6605018bd64ea2769f356662a (commit)
   via  fbc1b75c2692d82f729359b0aeec7ad959662d54 (commit)
   via  3d0e95f64c996d3d54b387f7688f988dd843ac6a (commit)
  from  a27be19f9c4990e97310c1fbf0005aaaf9bbf40e (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=479b0e2175da23aa995c19cc03d2abbfae1ea551
commit 479b0e2175da23aa995c19cc03d2abbfae1ea551
Merge: a27be19 c637e0c
Author: Brad King 
AuthorDate: Mon Oct 10 10:10:06 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Mon Oct 10 10:10:06 2016 -0400

Merge topic 'minor-cleanups' into next

c637e0c5 cmMakefile: Return a string from GetDefineFlags
fbc1b75c Test: Remove condition for CMake version no longer supported
3d0e95f6 cmLocalGenerator: Extract definition retrieval out of loop


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c637e0c53b5b81d6605018bd64ea2769f356662a
commit c637e0c53b5b81d6605018bd64ea2769f356662a
Author: Stephen Kelly 
AuthorDate: Sun Oct 9 10:47:45 2016 +0200
Commit: Brad King 
CommitDate: Mon Oct 10 10:09:54 2016 -0400

cmMakefile: Return a string from GetDefineFlags

Flip condition in GHS for readability.

diff --git a/Source/cmGhsMultiTargetGenerator.cxx 
b/Source/cmGhsMultiTargetGenerator.cxx
index 959dfdb..fac68f5 100644
--- a/Source/cmGhsMultiTargetGenerator.cxx
+++ b/Source/cmGhsMultiTargetGenerator.cxx
@@ -244,7 +244,7 @@ void 
cmGhsMultiTargetGenerator::SetCompilerFlags(std::string const& config,
   flags, this->GeneratorTarget, lang);
 
 // Append old-style preprocessor definition flags.
-if (std::string(" ") != std::string(this->Makefile->GetDefineFlags())) {
+if (this->Makefile->GetDefineFlags() != " ") {
   this->LocalGenerator->AppendFlags(flags,
 this->Makefile->GetDefineFlags());
 }
diff --git a/Source/cmMakefile.h b/Source/cmMakefile.h
index 40344ce..de7bead 100644
--- a/Source/cmMakefile.h
+++ b/Source/cmMakefile.h
@@ -447,7 +447,7 @@ public:
   /**
* Get a list of preprocessor define flags.
*/
-  const char* GetDefineFlags() const { return this->DefineFlags.c_str(); }
+  std::string GetDefineFlags() const { return this->DefineFlags; }
 
   /**
* Make sure CMake can write this file

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fbc1b75c2692d82f729359b0aeec7ad959662d54
commit fbc1b75c2692d82f729359b0aeec7ad959662d54
Author: Stephen Kelly 
AuthorDate: Sun Oct 9 10:47:44 2016 +0200
Commit: Brad King 
CommitDate: Mon Oct 10 10:09:54 2016 -0400

Test: Remove condition for CMake version no longer supported

diff --git a/Tests/FindPackageModeMakefileTest/CMakeLists.txt 
b/Tests/FindPackageModeMakefileTest/CMakeLists.txt
index 56fcc5d..23832da 100644
--- a/Tests/FindPackageModeMakefileTest/CMakeLists.txt
+++ b/Tests/FindPackageModeMakefileTest/CMakeLists.txt
@@ -20,16 +20,9 @@ if(UNIX  AND  "${CMAKE_GENERATOR}" MATCHES "Makefile" AND
 configure_file(FindFoo.cmake.in ${CMAKE_CURRENT_BINARY_DIR}/FindFoo.cmake 
@ONLY)
 
 # now set up the test:
-if (NOT CMAKE_VERSION VERSION_LESS 2.8.12)
-  file(GENERATE OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/cmakeExecutable.mk"
-CONTENT "CMAKE = \"$\"\n"
-  )
-else()
-  get_target_property(cmakeLocation cmake LOCATION)
-  file(WRITE "${CMAKE_CURRENT_BINARY_DIR}/cmakeExecutable.mk"
-"CMAKE = \"${cmakeLocation}\"\n"
-  )
-endif()
+file(GENERATE OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/cmakeExecutable.mk"
+  CONTENT "CMAKE = \"$\"\n"
+)
 configure_file(${CMAKE_CURRENT_SOURCE_DIR}/Makefile.in 
${CMAKE_CURRENT_BINARY_DIR}/ConfMakefile @ONLY)
 configure_file(${CMAKE_CURRENT_SOURCE_DIR}/main.cpp 
${CMAKE_CURRENT_BINARY_DIR}/main.cpp COPYONLY)
 

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3d0e95f64c996d3d54b387f7688f988dd843ac6a
commit 3d0e95f64c996d3d54b387f7688f988dd843ac6a
Author: Stephen Kelly 
AuthorDate: Sun Oct 9 10:47:44 2016 +0200
Commit: Brad King 
CommitDate: Mon Oct 10 10:09:54 2016 -0400

cmLocalGenerator: Extract definition retrieval out of loop

diff --git a/Source/cmLocalGenerator.cxx b/Source/cmLocalGenerator.cxx
index 2284cf9..025b82a 100644
--- a/Source/cmLocalGenerator.cxx
+++ b/Source/cmLocalGenerator.cxx
@@ -1176,12 +1176,13 @@ void 

[CMake] [SOLVED] RE: Crosscompilation woes

[Robert Bielik]

For reference: I went with Brads suggestion: 
https://gitlab.kitware.com/cmake/cmake/issues/16356

which seems to be working fine.

Regards
/R

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Robert Bielik
Sent: den 10 oktober 2016 14:00
To: Craig Scott 
Cc: Cmake@cmake.org
Subject: Re: [CMake] Crosscompilation woes

I am using a toolchain file! The CC and CXX environment variables are set by 
CMake (I assume, because I haven’t touched them).

I’ll disect the link to see what I’ve missed.

Regards
/R

From: Craig Scott [mailto:craig.sc...@crascit.com]
Sent: den 10 oktober 2016 13:56
To: Robert Bielik >
Cc: Cmake@cmake.org
Subject: Re: [CMake] Crosscompilation woes

Don't use environment variables to set the ARM compilers in your situation, use 
a toolchain file to specify them instead. Your CMake experience will generally 
be smoother if you specify cross-compile details via toolchain files. If you 
are following the method in the stackoverflow link I mentioned last time, the 
host part of the build will then pick up the host compilers and the ARM part of 
the build will use the compilers from the toolchain file.


On Mon, Oct 10, 2016 at 10:50 PM, Robert Bielik 
> wrote:
I’m trying to do this, but since I setup a cross compiling env. by setting 
C++ compiler, these settings get used when I run execute_process to setup the 
host build !! Thus I get the ARM version of the build tools anyway! :(

It seems that when execute_process is executed, the CC and CXX environment 
variables are set, which makes cmake use those when generating the makefiles.

Ideas are most welcome!

Regards
/R

From: Craig Scott 
[mailto:craig.sc...@crascit.com]
Sent: den 10 oktober 2016 10:47
To: Robert Bielik >
Cc: Cmake@cmake.org
Subject: Re: [CMake] Crosscompilation woes

Here's one possible solution (not perfect, but has been working in production 
for us for a while now for a similar scenario to what you describe):

http://stackoverflow.com/q/36084785/1938798

An alternative is a superbuild arrangement which would require a top level 
project to drive two sub-builds brought in via 
ExternalProject,
 one for the host and the other for arm. This is both better and worse, 
depending on your point of view, so you may need to do some 
research/experimenting to see which is a better fit for your situation.


On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik 
> wrote:
Hi all,

I am crosscompiling a project for arm (on linux i686), and use codegeneration 
tools within the project (together with add_custom_command). Of course, this 
will fail, since the tools are compiled for arm also and thus won't execute on 
my host system. So the tools need to be compiled for i686 whilst the rest for 
arm. I'm sure this can be handled by CMake although haven't done it before so 
would appreciate pointers :)

Regards
/Robert

--

Powered by www.kitware.com

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

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

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

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

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



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



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

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] FastBuild Generator

[Charles Huet]

Hi again.

I performed all the aforementioned actions, please check everything is OK
for you.

I have a few questions:
* the test CMake.CheckSourceTree does not work with Fastbuild, but I could
not get it to work with Ninja either, maybe I have an environment problem ?
* the test SimpleInstall requires trhe build tool to be able to run
multiple instances in the same hierarchy, which Fastbuild does not support.
Should I refactor the test to remove this requirement ? Or simply ignore
the test ?
* It seems SimpleInstall-Stage2 depends upon SimpleInstall, is this right ?

The branch I recently pushed has only a few tests failing, quite a few seem
to be related to a lack of non-source file dependencies as far as I can
tell.

Thanks.

Le jeu. 6 oct. 2016 à 19:33, Charles Huet  a écrit :

> >* Please use Utilities/Scripts/clang-format.bash for
> >  code style.  This is easy to apply automatically later
> >  so don't worry about it too much.
> I'll get on this soon, I like to have proper style.
>
>
> > * For final integration I'd like the commits to be squashed
>
> >  and arranged in an organized way.  This is hard to do until
> >  you have everything working though.
>
> Sure. For now there are the first few commits which I can't change much to
> keep proper attribuation, and a few commits on top which will be squashed
> together once the dev is complete (or maybe earlier if I feel like it).
>
> >* Please update the license notices to use the new style that
> >  we switched to in `master`.  Both C++ and .cmake notices
> >  changed.
> Will do.
>
> Le jeu. 6 oct. 2016 à 17:32, Brad King  a écrit :
>
> On 10/06/2016 08:32 AM, Charles Huet wrote:
> > Do you think it is time to start the review, or should it wait
> > until I have 100% of the tests passing ?
>
> Thanks for the update.  Generally my reviews for new features
> mostly look at documentation, tests, style, etc. rather than
> at implementation details (which can easily be fixed/changed
> later).  Therefore final review and integration should not start
> until everything is working.
>
> However, I'm happy to take quick glances at progress once in
> a while.  Here are some comments from the current version:
>
> * Please use Utilities/Scripts/clang-format.bash for
>   code style.  This is easy to apply automatically later
>   so don't worry about it too much.
>
> * For final integration I'd like the commits to be squashed
>   and arranged in an organized way.  This is hard to do until
>   you have everything working though.
>
> * Please update the license notices to use the new style that
>   we switched to in `master`.  Both C++ and .cmake notices
>   changed.
>
> 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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Patch: Don't emit warning when config file not found

[Brad King]

On 10/09/2016 03:24 PM, Christoph Grüninger wrote:
> * or loosing the output of tests and feature summary, as both tests are QUIET.
> 
> I'd prefer to write the error message to the CMakeError.log and reduce
> the output to one line. I think, the current behavior must be considered
> a bug.

The default behavior evolved over many years to satisfy many use cases and
give people the information they need to resolve real problems.  It is not
going to change.  However, if you'd like to propose additional options to
these interfaces to get the behavior you want then that would be fine.
Perhaps find_package could gain an ``OPTIONAL`` switch.  I'm not very
familiar with feature_summary so I'm not sure what that would need off the
top of my head.

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Error with ninja generator when using target_link_library with the debug keyword

[Luis Díaz Más]

Hi,

I just want to confirm that I have the same problem on Windows with the
Ninja generator. Even when I always use both keywords (debug & optimized)
in my *target_link_libraries *commands I still got a *ninja.build *file
that has bad $-escape characters.

I think that this problem is happening only when I tried to compile a
library twice (shared and static) and I tried to propagate the
*LINK_LIBRARIES* property from the shared library to the static one:

add_library(mylib SHARED ${mylib_all_sources})
add_library(mylib_static STATIC EXCLUDE_FROM_ALL ${mylib
_all_sources})

target_link_libraries(mylib PUBLIC ${SOME_LIBS})
target_link_libraries(mylib_static PUBLIC
$)

Only in that situation is when I got the weird bad $-escape characters on
the ninja.build file. This is an example of the line with these problems:

  LINK_LIBRARIES = C:\myProject\buildRelease\bin64\library1.lib
  C:\myProject\buildRelease\bin64\library2.lib
  C:\myProject\libs\gmock.lib
  C:\myProject\libs\CGAL-vc120-mt-4.4.lib
  C:\myProject\libs\exiv2.lib
  C:\myProject\libs\ceres.lib
  ... // removing some lines
  $<$:C:/myProject\libs/CGAL-vc120-mt-4.4.lib>
  $<$:C:/myProject\libs/CGAL-vc120-mt-gd-4.4.lib>
  ... // removing some lines
  $<$:C:/myProject\libs/exiv2.lib>
  $<$:C:/myProject\libs/exiv2d.lib>
  $<$:C:/myProject\libs/ceres.lib>
  $<$:C:/myProject\libs/ceres-debug.lib>
  ...
  kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib comdlg32.lib advapi32.lib

I will try to create a minimum example to reproduce this issue.

Cheers,
Luis


2016-10-05 16:39 GMT+02:00 Luis Díaz Más :

> Hi all,
>
> I have found a problem while configuring a project and I want to share the
> experience with you to figure out whether it is a known problem or a bug in
> CMake.
>
> In some cases I use the cmake command *target_link_libraries *specifying
> different libraries for the *debug* and *optimized* modes. This normally
> work as expected. However recently we got a problem with the Ninja
> generator. This is what I could see in the console when I try to compile
> the project:
>
> ninja: error: build.ninja:4956: bad $-escape (literal $ must be written as
> $$)
>
>
> The content of the file in that particular line has something like this:
>
> $<$:/home/luis///lib/libCGAL.so>
>
> Examining my cmake configuration I noticed that a colleague introduced
> something like that in the *target_link_libraries* call:
>
> ${ZLIB_LIBRARIES}
> debug;${CGAL_LIB}
> ${GMP_LIB}
>
> If we specify the debug & optimized modes we do not have problems. However
> in this particular case, it seems that we only need to link against the
> CGAL in debug mode and not in release mode. Note that with a Make generator
> we can compile normally the project.
>
> The work around for this case is to link normally against CGAL when we are
> in Debug mode:
>
> if (${CMAKE_BUILD_TYPE} STREQUAL Debug)
> target_link_libraries(myTarget ${CGAL_LIB}
> endif()
>
> So ... the questions are:
>
>
>- Is it possible to use *target_link_libraries *only with one of the
>modes (debug  / optimized) ?
>- The Make generator works properly for this case. Could it be a bug
>with the Ninja generator? I tried with the most recent versions of CMake &
>Ninja.
>
> Best regards,
> Luis Diaz Mas
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Crosscompilation woes

[Robert Bielik]

I am using a toolchain file! The CC and CXX environment variables are set by 
CMake (I assume, because I haven’t touched them).

I’ll disect the link to see what I’ve missed.

Regards
/R

From: Craig Scott [mailto:craig.sc...@crascit.com]
Sent: den 10 oktober 2016 13:56
To: Robert Bielik 
Cc: Cmake@cmake.org
Subject: Re: [CMake] Crosscompilation woes

Don't use environment variables to set the ARM compilers in your situation, use 
a toolchain file to specify them instead. Your CMake experience will generally 
be smoother if you specify cross-compile details via toolchain files. If you 
are following the method in the stackoverflow link I mentioned last time, the 
host part of the build will then pick up the host compilers and the ARM part of 
the build will use the compilers from the toolchain file.


On Mon, Oct 10, 2016 at 10:50 PM, Robert Bielik 
> wrote:
I’m trying to do this, but since I setup a cross compiling env. by setting 
C++ compiler, these settings get used when I run execute_process to setup the 
host build !! Thus I get the ARM version of the build tools anyway! :(

It seems that when execute_process is executed, the CC and CXX environment 
variables are set, which makes cmake use those when generating the makefiles.

Ideas are most welcome!

Regards
/R

From: Craig Scott 
[mailto:craig.sc...@crascit.com]
Sent: den 10 oktober 2016 10:47
To: Robert Bielik >
Cc: Cmake@cmake.org
Subject: Re: [CMake] Crosscompilation woes

Here's one possible solution (not perfect, but has been working in production 
for us for a while now for a similar scenario to what you describe):

http://stackoverflow.com/q/36084785/1938798

An alternative is a superbuild arrangement which would require a top level 
project to drive two sub-builds brought in via 
ExternalProject,
 one for the host and the other for arm. This is both better and worse, 
depending on your point of view, so you may need to do some 
research/experimenting to see which is a better fit for your situation.


On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik 
> wrote:
Hi all,

I am crosscompiling a project for arm (on linux i686), and use codegeneration 
tools within the project (together with add_custom_command). Of course, this 
will fail, since the tools are compiled for arm also and thus won't execute on 
my host system. So the tools need to be compiled for i686 whilst the rest for 
arm. I'm sure this can be handled by CMake although haven't done it before so 
would appreciate pointers :)

Regards
/Robert

--

Powered by www.kitware.com

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

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

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

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

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



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



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

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Crosscompilation woes

[Craig Scott]

Don't use environment variables to set the ARM compilers in your situation,
use a toolchain file to specify them instead. Your CMake experience will
generally be smoother if you specify cross-compile details via toolchain
files. If you are following the method in the stackoverflow link I
mentioned last time, the host part of the build will then pick up the host
compilers and the ARM part of the build will use the compilers from the
toolchain file.


On Mon, Oct 10, 2016 at 10:50 PM, Robert Bielik 
wrote:

> I’m trying to do this, but since I setup a cross compiling env. by setting
> C++ compiler, these settings get used when I run execute_process to setup
> the host build !! Thus I get the ARM version of the build tools anyway! :(
>
>
>
> It seems that when execute_process is executed, the CC and CXX environment
> variables are set, which makes cmake use those when generating the
> makefiles.
>
>
>
> Ideas are most welcome!
>
>
>
> Regards
>
> /R
>
>
>
> *From:* Craig Scott [mailto:craig.sc...@crascit.com]
> *Sent:* den 10 oktober 2016 10:47
> *To:* Robert Bielik 
> *Cc:* Cmake@cmake.org
> *Subject:* Re: [CMake] Crosscompilation woes
>
>
>
> Here's one possible solution (not perfect, but has been working in
> production for us for a while now for a similar scenario to what you
> describe):
>
>
>
> http://stackoverflow.com/q/36084785/1938798
>
>
>
> An alternative is a superbuild arrangement which would require a top level
> project to drive two sub-builds brought in via ExternalProject
> , one
> for the host and the other for arm. This is both better and worse,
> depending on your point of view, so you may need to do some
> research/experimenting to see which is a better fit for your situation.
>
>
>
>
>
> On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik 
> wrote:
>
> Hi all,
>
> I am crosscompiling a project for arm (on linux i686), and use
> codegeneration tools within the project (together with add_custom_command).
> Of course, this will fail, since the tools are compiled for arm also and
> thus won't execute on my host system. So the tools need to be compiled for
> i686 whilst the rest for arm. I'm sure this can be handled by CMake
> although haven't done it before so would appreciate pointers :)
>
> Regards
> /Robert
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
>
>
>
>
> --
>
> Craig Scott
>
> Melbourne, Australia
>
> https://crascit.com
>



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

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Crosscompilation woes

[Robert Bielik]

I’m trying to do this, but since I setup a cross compiling env. by setting 
C++ compiler, these settings get used when I run execute_process to setup the 
host build !! Thus I get the ARM version of the build tools anyway! :(

It seems that when execute_process is executed, the CC and CXX environment 
variables are set, which makes cmake use those when generating the makefiles.

Ideas are most welcome!

Regards
/R

From: Craig Scott [mailto:craig.sc...@crascit.com]
Sent: den 10 oktober 2016 10:47
To: Robert Bielik 
Cc: Cmake@cmake.org
Subject: Re: [CMake] Crosscompilation woes

Here's one possible solution (not perfect, but has been working in production 
for us for a while now for a similar scenario to what you describe):

http://stackoverflow.com/q/36084785/1938798

An alternative is a superbuild arrangement which would require a top level 
project to drive two sub-builds brought in via 
ExternalProject,
 one for the host and the other for arm. This is both better and worse, 
depending on your point of view, so you may need to do some 
research/experimenting to see which is a better fit for your situation.


On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik 
> wrote:
Hi all,

I am crosscompiling a project for arm (on linux i686), and use codegeneration 
tools within the project (together with add_custom_command). Of course, this 
will fail, since the tools are compiled for arm also and thus won't execute on 
my host system. So the tools need to be compiled for i686 whilst the rest for 
arm. I'm sure this can be handled by CMake although haven't done it before so 
would appreciate pointers :)

Regards
/Robert

--

Powered by www.kitware.com

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

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

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

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

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



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

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Crosscompilation woes

[Robert Bielik]

Aha, I see. You're using find_package. That will automatically get you the 
binaries for your host system.

My problem is different, I need to build my binaries with CMake before using 
them, and I need to build them with i686 (instead of arm).

Regards
/R

From: portolan [mailto:michele.porto...@imag.fr]
Sent: den 10 oktober 2016 13:14
To: Robert Bielik ; Cmake@cmake.org
Subject: Re: [CMake] Crosscompilation woes


It is pretty much standard. I wrote the toolchain file adapting different 
examples.

the Cmakelist is for the subdirectory of my parser (called SIT_parser). The 
trick si that I use a custom command for Lex/Yacc, so even when cross-compiling 
it is still correctly called.



Michele



Le 10/10/2016 à 12:48, Robert Bielik a écrit :
Ok, I cannot get this to work. The source files to be generated with 
add_custom_command have property GENERATED set to ON, but cmake does not 
adhere, and tries to use the tool binaries of the target system.

Michele, would you be ok with sharing your cmake code for this particular bit ?

Regards
/R

From: portolan [mailto:michele.porto...@imag.fr]
Sent: den 10 oktober 2016 11:33
To: Robert Bielik ; 
Craig Scott 
Cc: Cmake@cmake.org
Subject: Re: [CMake] Crosscompilation woes


I cannot answer your question: I am a newcomer to Cmake (I have been using it 
for less than 6 months) and on my build system I have 3.6, so I never really 
looked at the previous versions.

Sorry,



Michele

Le 10/10/2016 à 11:30, Robert Bielik a écrit :
Thank you Michele,

This is exactly what I'm after. You specify cmake v3.6 docs ? Is it only 
working from 3.6.x ? I have 3.5.2 on my build system.

Regards
/Robert

From: portolan [mailto:michele.porto...@imag.fr]
Sent: den 10 oktober 2016 11:27
To: Robert Bielik ; 
Craig Scott 
Cc: Cmake@cmake.org
Subject: Re: [CMake] Crosscompilation woes


In my project I build on Linux i686 and I use a Toolchain file to specify the 
ARM cross-compiler

https://cmake.org/cmake/help/v3.6/manual/cmake-toolchains.7.html
The nice thing is that if you mark some files as "generated" CMAKE will 
automatically use the build rather than the target toolchains. For instance, I 
have a Flex/Byson compiler that is generated locally on i686 , but then 
compiled for ARM.

Regards,

Michele
Le 10/10/2016 à 11:10, Robert Bielik a écrit :
Thanks Craig,

Your solution will work for me I think.

Regards
/R

From: Craig Scott [mailto:craig.sc...@crascit.com]
Sent: den 10 oktober 2016 10:47
To: Robert Bielik 
Cc: Cmake@cmake.org
Subject: Re: [CMake] Crosscompilation woes

Here's one possible solution (not perfect, but has been working in production 
for us for a while now for a similar scenario to what you describe):

http://stackoverflow.com/q/36084785/1938798

An alternative is a superbuild arrangement which would require a top level 
project to drive two sub-builds brought in via 
ExternalProject,
 one for the host and the other for arm. This is both better and worse, 
depending on your point of view, so you may need to do some 
research/experimenting to see which is a better fit for your situation.


On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik 
> wrote:
Hi all,

I am crosscompiling a project for arm (on linux i686), and use codegeneration 
tools within the project (together with add_custom_command). Of course, this 
will fail, since the tools are compiled for arm also and thus won't execute on 
my host system. So the tools need to be compiled for i686 whilst the rest for 
arm. I'm sure this can be handled by CMake although haven't done it before so 
would appreciate pointers :)

Regards
/Robert

--

Powered by www.kitware.com

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

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

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

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

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



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









-- 

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 

Re: [CMake] Crosscompilation woes

[portolan]

It is pretty much standard. I wrote the toolchain file adapting 
different examples.


the Cmakelist is for the subdirectory of my parser (called SIT_parser). 
The trick si that I use a custom command for Lex/Yacc, so even when 
cross-compiling it is still correctly called.



Michele



Le 10/10/2016 à 12:48, Robert Bielik a écrit :


Ok, I cannot get this to work. The source files to be generated with 
add_custom_command have property GENERATED set to ON, but cmake does 
not adhere, and tries to use the tool binaries of the target system.


Michele, would you be ok with sharing your cmake code for this 
particular bit ?


Regards

/R

*From:*portolan [mailto:michele.porto...@imag.fr]
*Sent:* den 10 oktober 2016 11:33
*To:* Robert Bielik ; Craig Scott 


*Cc:* Cmake@cmake.org
*Subject:* Re: [CMake] Crosscompilation woes

I cannot answer your question: I am a newcomer to Cmake (I have been 
using it for less than 6 months) and on my build system I have 3.6, so 
I never really looked at the previous versions.


Sorry,

Michele

Le 10/10/2016 à 11:30, Robert Bielik a écrit :

Thank you Michele,

This is exactly what I’m after. You specify cmake v3.6 docs ? Is
it only working from 3.6.x ? I have 3.5.2 on my build system.

Regards

/Robert

*From:*portolan [mailto:michele.porto...@imag.fr]
*Sent:* den 10 oktober 2016 11:27
*To:* Robert Bielik 
; Craig Scott
 
*Cc:* Cmake@cmake.org 
*Subject:* Re: [CMake] Crosscompilation woes

In my project I build on Linux i686 and I use a Toolchain file to
specify the ARM cross-compiler

https://cmake.org/cmake/help/v3.6/manual/cmake-toolchains.7.html

The nice thing is that if you mark some files as "generated" CMAKE
will automatically use the build rather than the target
toolchains. For instance, I have a Flex/Byson compiler that is
generated locally on i686 , but then compiled for ARM.

Regards,

Michele

Le 10/10/2016 à 11:10, Robert Bielik a écrit :

Thanks Craig,

Your solution will work for me I think.

Regards

/R

*From:*Craig Scott [mailto:craig.sc...@crascit.com]
*Sent:* den 10 oktober 2016 10:47
*To:* Robert Bielik 

*Cc:* Cmake@cmake.org 
*Subject:* Re: [CMake] Crosscompilation woes

Here's one possible solution (not perfect, but has been
working in production for us for a while now for a similar
scenario to what you describe):

http://stackoverflow.com/q/36084785/1938798

An alternative is a superbuild arrangement which would require
a top level project to drive two sub-builds brought in via
ExternalProject
,
one for the host and the other for arm. This is both better
and worse, depending on your point of view, so you may need to
do some research/experimenting to see which is a better fit
for your situation.

On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik
> wrote:

Hi all,

I am crosscompiling a project for arm (on linux i686), and
use codegeneration tools within the project (together with
add_custom_command). Of course, this will fail, since the
tools are compiled for arm also and thus won't execute on
my host system. So the tools need to be compiled for i686
whilst the rest for arm. I'm sure this can be handled by
CMake although haven't done it before so would appreciate
pointers :)

Regards
/Robert

--

Powered by www.kitware.com 

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


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

CMake Support: http://cmake.org/cmake/help/support.html

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

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

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



-- 


Craig Scott

Melbourne, 

Re: [CMake] Crosscompilation woes

[Robert Bielik]

Ok, I cannot get this to work. The source files to be generated with 
add_custom_command have property GENERATED set to ON, but cmake does not 
adhere, and tries to use the tool binaries of the target system.

Michele, would you be ok with sharing your cmake code for this particular bit ?

Regards
/R

From: portolan [mailto:michele.porto...@imag.fr]
Sent: den 10 oktober 2016 11:33
To: Robert Bielik ; Craig Scott 

Cc: Cmake@cmake.org
Subject: Re: [CMake] Crosscompilation woes


I cannot answer your question: I am a newcomer to Cmake (I have been using it 
for less than 6 months) and on my build system I have 3.6, so I never really 
looked at the previous versions.

Sorry,



Michele

Le 10/10/2016 à 11:30, Robert Bielik a écrit :
Thank you Michele,

This is exactly what I'm after. You specify cmake v3.6 docs ? Is it only 
working from 3.6.x ? I have 3.5.2 on my build system.

Regards
/Robert

From: portolan [mailto:michele.porto...@imag.fr]
Sent: den 10 oktober 2016 11:27
To: Robert Bielik ; 
Craig Scott 
Cc: Cmake@cmake.org
Subject: Re: [CMake] Crosscompilation woes


In my project I build on Linux i686 and I use a Toolchain file to specify the 
ARM cross-compiler

https://cmake.org/cmake/help/v3.6/manual/cmake-toolchains.7.html
The nice thing is that if you mark some files as "generated" CMAKE will 
automatically use the build rather than the target toolchains. For instance, I 
have a Flex/Byson compiler that is generated locally on i686 , but then 
compiled for ARM.

Regards,

Michele
Le 10/10/2016 à 11:10, Robert Bielik a écrit :
Thanks Craig,

Your solution will work for me I think.

Regards
/R

From: Craig Scott [mailto:craig.sc...@crascit.com]
Sent: den 10 oktober 2016 10:47
To: Robert Bielik 
Cc: Cmake@cmake.org
Subject: Re: [CMake] Crosscompilation woes

Here's one possible solution (not perfect, but has been working in production 
for us for a while now for a similar scenario to what you describe):

http://stackoverflow.com/q/36084785/1938798

An alternative is a superbuild arrangement which would require a top level 
project to drive two sub-builds brought in via 
ExternalProject,
 one for the host and the other for arm. This is both better and worse, 
depending on your point of view, so you may need to do some 
research/experimenting to see which is a better fit for your situation.


On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik 
> wrote:
Hi all,

I am crosscompiling a project for arm (on linux i686), and use codegeneration 
tools within the project (together with add_custom_command). Of course, this 
will fail, since the tools are compiled for arm also and thus won't execute on 
my host system. So the tools need to be compiled for i686 whilst the rest for 
arm. I'm sure this can be handled by CMake although haven't done it before so 
would appreciate pointers :)

Regards
/Robert

--

Powered by www.kitware.com

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

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

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

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

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



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





-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] CMake doesn't detect Microsoft Build Tools 2015 on Windows 10

[Eduard Wirch]

Hi

I've installed build tools from here: 
http://landinghub.visualstudio.com/visual-cpp-build-tools
But CMake will automatically detect (and choose) Visual Studio 8 (installed 
here as well) instead.

Looking into the source:

const std::string vsregBase =
  "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\";
std::vector vsVerions;
vsVerions.push_back("VisualStudio\\");
vsVerions.push_back("VCExpress\\");
vsVerions.push_back("WDExpress\\");
struct VSRegistryEntryName
{
  const char* MSVersion;
  const char* GeneratorName;
};
VSRegistryEntryName version[] = {
  /* clang-format needs this comment to break after the opening brace */
  { "7.1", "Visual Studio 7 .NET 2003" },
  { "8.0", "Visual Studio 8 2005" },
  { "9.0", "Visual Studio 9 2008" },
  { "10.0", "Visual Studio 10 2010" },
  { "11.0", "Visual Studio 11 2012" },
  { "12.0", "Visual Studio 12 2013" },
  { "14.0", "Visual Studio 14 2015" },
  { "15.0", "Visual Studio 15" },
  { 0, 0 }
};
for (int i = 0; version[i].MSVersion != 0; i++) {
  for (size_t b = 0; b < vsVerions.size(); b++) {
std::string reg = vsregBase + vsVerions[b] + version[i].MSVersion;
reg += ";InstallDir]";
cmSystemTools::ExpandRegistryValues(reg, cmSystemTools::KeyWOW64_32);
if (!(reg == "/registry")) {
  installedCompiler = version[i].GeneratorName;
  break;
}
  }
}

CMake will look for 
'HKLM\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\InstallDir'. This key is 
not present indeed. When specified explicitly:
cmake . -G "Visual Studio 14 2015"
CMake will correctly detect the compiler and build without problems.

These keys might be helpful when looking for Build Tools:


[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\Setup\VC]
"ProductDir"="C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\"


[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\Setup\SSDT]
"InstallDir"="C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\"
"VersionNumber"="14.0.50616.0"

Am I missing something or is this a bug which should be reported to issue 
tracker?

Cheers,
Eduard
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Crosscompilation woes

[portolan]

In my project I build on Linux i686 and I use a Toolchain file to 
specify the ARM cross-compiler


https://cmake.org/cmake/help/v3.6/manual/cmake-toolchains.7.html

The nice thing is that if you mark some files as "generated" CMAKE will 
automatically use the build rather than the target toolchains. For 
instance, I have a Flex/Byson compiler that is generated locally on i686 
, but then compiled for ARM.


Regards,

Michele

Le 10/10/2016 à 11:10, Robert Bielik a écrit :


Thanks Craig,

Your solution will work for me I think.

Regards

/R

*From:*Craig Scott [mailto:craig.sc...@crascit.com]
*Sent:* den 10 oktober 2016 10:47
*To:* Robert Bielik 
*Cc:* Cmake@cmake.org
*Subject:* Re: [CMake] Crosscompilation woes

Here's one possible solution (not perfect, but has been working in 
production for us for a while now for a similar scenario to what you 
describe):


http://stackoverflow.com/q/36084785/1938798

An alternative is a superbuild arrangement which would require a top 
level project to drive two sub-builds brought in via ExternalProject 
, one 
for the host and the other for arm. This is both better and worse, 
depending on your point of view, so you may need to do some 
research/experimenting to see which is a better fit for your situation.


On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik 
> wrote:


Hi all,

I am crosscompiling a project for arm (on linux i686), and use
codegeneration tools within the project (together with
add_custom_command). Of course, this will fail, since the tools
are compiled for arm also and thus won't execute on my host
system. So the tools need to be compiled for i686 whilst the rest
for arm. I'm sure this can be handled by CMake although haven't
done it before so would appreciate pointers :)

Regards
/Robert

--

Powered by www.kitware.com 

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


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

CMake Support: http://cmake.org/cmake/help/support.html

CMake Consulting: http://cmake.org/cmake/help/consulting.html

CMake Training Courses: http://cmake.org/cmake/help/training.html


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

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



--

Craig Scott

Melbourne, Australia

https://crascit.com





-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Crosscompilation woes

[portolan]

I cannot answer your question: I am a newcomer to Cmake (I have been 
using it for less than 6 months) and on my build system I have 3.6, so I 
never really looked at the previous versions.


Sorry,


Michele


Le 10/10/2016 à 11:30, Robert Bielik a écrit :


Thank you Michele,

This is exactly what I’m after. You specify cmake v3.6 docs ? Is it 
only working from 3.6.x ? I have 3.5.2 on my build system.


Regards

/Robert

*From:*portolan [mailto:michele.porto...@imag.fr]
*Sent:* den 10 oktober 2016 11:27
*To:* Robert Bielik ; Craig Scott 


*Cc:* Cmake@cmake.org
*Subject:* Re: [CMake] Crosscompilation woes

In my project I build on Linux i686 and I use a Toolchain file to 
specify the ARM cross-compiler


https://cmake.org/cmake/help/v3.6/manual/cmake-toolchains.7.html

The nice thing is that if you mark some files as "generated" CMAKE 
will automatically use the build rather than the target toolchains. 
For instance, I have a Flex/Byson compiler that is generated locally 
on i686 , but then compiled for ARM.


Regards,

Michele

Le 10/10/2016 à 11:10, Robert Bielik a écrit :

Thanks Craig,

Your solution will work for me I think.

Regards

/R

*From:*Craig Scott [mailto:craig.sc...@crascit.com]
*Sent:* den 10 oktober 2016 10:47
*To:* Robert Bielik 

*Cc:* Cmake@cmake.org 
*Subject:* Re: [CMake] Crosscompilation woes

Here's one possible solution (not perfect, but has been working in
production for us for a while now for a similar scenario to what
you describe):

http://stackoverflow.com/q/36084785/1938798

An alternative is a superbuild arrangement which would require a
top level project to drive two sub-builds brought in via
ExternalProject
,
one for the host and the other for arm. This is both better and
worse, depending on your point of view, so you may need to do some
research/experimenting to see which is a better fit for your
situation.

On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik
> wrote:

Hi all,

I am crosscompiling a project for arm (on linux i686), and use
codegeneration tools within the project (together with
add_custom_command). Of course, this will fail, since the
tools are compiled for arm also and thus won't execute on my
host system. So the tools need to be compiled for i686 whilst
the rest for arm. I'm sure this can be handled by CMake
although haven't done it before so would appreciate pointers :)

Regards
/Robert

--

Powered by www.kitware.com 

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


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

CMake Support: http://cmake.org/cmake/help/support.html

CMake Consulting: http://cmake.org/cmake/help/consulting.html

CMake Training Courses:
http://cmake.org/cmake/help/training.html


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

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



-- 


Craig Scott

Melbourne, Australia

https://crascit.com





-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Crosscompilation woes

[Robert Bielik]

Thank you Michele,

This is exactly what I'm after. You specify cmake v3.6 docs ? Is it only 
working from 3.6.x ? I have 3.5.2 on my build system.

Regards
/Robert

From: portolan [mailto:michele.porto...@imag.fr]
Sent: den 10 oktober 2016 11:27
To: Robert Bielik ; Craig Scott 

Cc: Cmake@cmake.org
Subject: Re: [CMake] Crosscompilation woes


In my project I build on Linux i686 and I use a Toolchain file to specify the 
ARM cross-compiler

https://cmake.org/cmake/help/v3.6/manual/cmake-toolchains.7.html
The nice thing is that if you mark some files as "generated" CMAKE will 
automatically use the build rather than the target toolchains. For instance, I 
have a Flex/Byson compiler that is generated locally on i686 , but then 
compiled for ARM.

Regards,

Michele
Le 10/10/2016 à 11:10, Robert Bielik a écrit :
Thanks Craig,

Your solution will work for me I think.

Regards
/R

From: Craig Scott [mailto:craig.sc...@crascit.com]
Sent: den 10 oktober 2016 10:47
To: Robert Bielik 
Cc: Cmake@cmake.org
Subject: Re: [CMake] Crosscompilation woes

Here's one possible solution (not perfect, but has been working in production 
for us for a while now for a similar scenario to what you describe):

http://stackoverflow.com/q/36084785/1938798

An alternative is a superbuild arrangement which would require a top level 
project to drive two sub-builds brought in via 
ExternalProject,
 one for the host and the other for arm. This is both better and worse, 
depending on your point of view, so you may need to do some 
research/experimenting to see which is a better fit for your situation.


On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik 
> wrote:
Hi all,

I am crosscompiling a project for arm (on linux i686), and use codegeneration 
tools within the project (together with add_custom_command). Of course, this 
will fail, since the tools are compiled for arm also and thus won't execute on 
my host system. So the tools need to be compiled for i686 whilst the rest for 
arm. I'm sure this can be handled by CMake although haven't done it before so 
would appreciate pointers :)

Regards
/Robert

--

Powered by www.kitware.com

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

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

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

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

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



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



-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Crosscompilation woes

[Robert Bielik]

Thanks Craig,

Your solution will work for me I think.

Regards
/R

From: Craig Scott [mailto:craig.sc...@crascit.com]
Sent: den 10 oktober 2016 10:47
To: Robert Bielik 
Cc: Cmake@cmake.org
Subject: Re: [CMake] Crosscompilation woes

Here's one possible solution (not perfect, but has been working in production 
for us for a while now for a similar scenario to what you describe):

http://stackoverflow.com/q/36084785/1938798

An alternative is a superbuild arrangement which would require a top level 
project to drive two sub-builds brought in via 
ExternalProject,
 one for the host and the other for arm. This is both better and worse, 
depending on your point of view, so you may need to do some 
research/experimenting to see which is a better fit for your situation.


On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik 
> wrote:
Hi all,

I am crosscompiling a project for arm (on linux i686), and use codegeneration 
tools within the project (together with add_custom_command). Of course, this 
will fail, since the tools are compiled for arm also and thus won't execute on 
my host system. So the tools need to be compiled for i686 whilst the rest for 
arm. I'm sure this can be handled by CMake although haven't done it before so 
would appreciate pointers :)

Regards
/Robert

--

Powered by www.kitware.com

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

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

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

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

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



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

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Crosscompilation woes

[Craig Scott]

Here's one possible solution (not perfect, but has been working in
production for us for a while now for a similar scenario to what you
describe):

http://stackoverflow.com/q/36084785/1938798

An alternative is a superbuild arrangement which would require a top level
project to drive two sub-builds brought in via ExternalProject
, one for
the host and the other for arm. This is both better and worse, depending on
your point of view, so you may need to do some research/experimenting to
see which is a better fit for your situation.


On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik 
wrote:

> Hi all,
>
> I am crosscompiling a project for arm (on linux i686), and use
> codegeneration tools within the project (together with add_custom_command).
> Of course, this will fail, since the tools are compiled for arm also and
> thus won't execute on my host system. So the tools need to be compiled for
> i686 whilst the rest for arm. I'm sure this can be handled by CMake
> although haven't done it before so would appreciate pointers :)
>
> Regards
> /Robert
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>



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

Powered by www.kitware.com

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

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

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

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

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

[CMake] Crosscompilation woes

[Robert Bielik]

Hi all,

I am crosscompiling a project for arm (on linux i686), and use codegeneration 
tools within the project (together with add_custom_command). Of course, this 
will fail, since the tools are compiled for arm also and thus won't execute on 
my host system. So the tools need to be compiled for i686 whilst the rest for 
arm. I'm sure this can be handled by CMake although haven't done it before so 
would appreciate pointers :)

Regards
/Robert

-- 

Powered by www.kitware.com

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

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

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

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

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