[Cmake-commits] CMake branch, master, updated. v3.5.1-450-gc42aa3e

[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  c42aa3ed8b11d96fe27d2cdda185da0ed45f38ef (commit)
  from  003d4e57521a876b7340ed164a737d99eabb164d (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=c42aa3ed8b11d96fe27d2cdda185da0ed45f38ef
commit c42aa3ed8b11d96fe27d2cdda185da0ed45f38ef
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Fri Apr 15 00:01:05 2016 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Fri Apr 15 00:01:05 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index a42df4f..2a5b01a 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 5)
-set(CMake_VERSION_PATCH 20160414)
+set(CMake_VERSION_PATCH 20160415)
 #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-developers] [CMake 0016065]: Building CUDA files fails when compile definitions contains parenthesis

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=16065 
== 
Reported By:Guillaume Dumont
Assigned To:
== 
Project:CMake
Issue ID:   16065
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-04-14 19:57 EDT
Last Modified:  2016-04-14 19:57 EDT
== 
Summary:Building CUDA files fails when compile definitions
contains parenthesis
Description: 
When calling cuda_wrap_srcs with the OPTIONS argument or when adding compile
definitions via add_definitions the build fails when the definitions contain
parentheses. For example,

add_definitions("-DFOO_BAR_EXPORT=declspec\(dllimport\)")

generates:

set(nvcc_flags -DFOO_BAR_EXPORT=declspec(dllimport))

which makes the build fail. When the parentheses are escaped like so:

add_definitions("-DFOO_BAR_EXPORT=declspec\\\(dllimport\\\)")

we get:

set(nvcc_flags -DFOO_BAR_EXPORT=declspec\(dllimport\))

and everything is fine.

This is similar to issue: https://cmake.org/Bug/view.php?id=15919

Maybe a similar fix can be applied?
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-04-14 19:57 Guillaume DumontNew Issue
==

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] FindMPI with intel MPI wrappers

[Dominic Meiser]

Hi,

I've been having trouble with the detection of the MPI libraries
when using intel's MPI compiler wrappers.  The issue is that

- The wrappers use /LIBPATH: instead of -L to specify the library
  search path
- The wrappers link against static versions of the mpi libraries
  without using -l.

I'm attaching a couple of patches to deal with this.  Are patches
to the mailing list still the recommended way to submit changes?
Or are pull requests on github preferred?

Cheers,
Dominic


-- 
Dominic Meiser
Tech-X Corporation - 5621 Arapahoe Avenue - Boulder, CO 80303
>From 879532ce66d87d9733e0edca9d54d95823880dff Mon Sep 17 00:00:00 2001
From: Dominic Meiser 
Date: Thu, 14 Apr 2016 11:01:43 -0600
Subject: [PATCH 1/2] Accept /LIBPATH for  specification of linker paths.

The intel MPI wrappers use this form of -L to specify library locations.
---
 Modules/FindMPI.cmake | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Modules/FindMPI.cmake b/Modules/FindMPI.cmake
index 0e406e0..0bf5549 100644
--- a/Modules/FindMPI.cmake
+++ b/Modules/FindMPI.cmake
@@ -357,10 +357,11 @@ function (interrogate_mpi_compiler lang try_libs)
 endif()
 
 # Extract linker paths from the link command line
-string(REGEX MATCHALL "(^| |-Wl,)-L([^\" ]+|\"[^\"]+\")" 
MPI_ALL_LINK_PATHS "${MPI_LINK_CMDLINE}")
+string(REGEX MATCHALL "(^| |-Wl,)(-L|/LIBPATH:)([^\" ]+|\"[^\"]+\")" 
MPI_ALL_LINK_PATHS "${MPI_LINK_CMDLINE}")
 set(MPI_LINK_PATH)
 foreach(LPATH ${MPI_ALL_LINK_PATHS})
   string(REGEX REPLACE "^(| |-Wl,)-L" "" LPATH ${LPATH})
+  string(REGEX REPLACE "/LIBPATH:" "" LPATH ${LPATH})
   string(REPLACE "//" "/" LPATH ${LPATH})
   list(APPEND MPI_LINK_PATH ${LPATH})
 endforeach()
-- 
2.6.2.450.g259b5e6

>From 62a9bf47f07b5853a7c857545f243844ab3b5ca6 Mon Sep 17 00:00:00 2001
From: Dominic Meiser 
Date: Thu, 14 Apr 2016 11:03:21 -0600
Subject: [PATCH 2/2] Fix for static MPI libraries.

The intel MPI compiler wrappers link against static MPI libraries simply
by listing the libraries (no `-l`).
---
 Modules/FindMPI.cmake | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/Modules/FindMPI.cmake b/Modules/FindMPI.cmake
index 0bf5549..fd9cc19 100644
--- a/Modules/FindMPI.cmake
+++ b/Modules/FindMPI.cmake
@@ -386,6 +386,13 @@ function (interrogate_mpi_compiler lang try_libs)
 # Extract the set of libraries to link against from the link command
 # line
 string(REGEX MATCHALL "(^| )-l([^\" ]+|\"[^\"]+\")" MPI_LIBNAMES 
"${MPI_LINK_CMDLINE}")
+if(WIN32)
+  # The intel wrappers on windows link against static versions of the 
MPI libraries.
+  # The static libraries are simply listed on the command line without 
-l.
+  # For instance: " icl ... impi.lib "
+  string(REGEX MATCHALL "(^| )([^\" ]+)\\.lib" tmp 
"${MPI_LINK_CMDLINE}")
+  list(APPEND MPI_LIBNAMES ${tmp})
+endif()
 
 # add the compiler implicit directories because some compilers
 # such as the intel compiler have libraries that show up
@@ -400,6 +407,10 @@ function (interrogate_mpi_compiler lang try_libs)
 # to link against in an MPI program
 foreach(LIB ${MPI_LIBNAMES})
   string(REGEX REPLACE "^ ?-l" "" LIB ${LIB})
+  if(WIN32)
+string(REGEX REPLACE "\\.lib$" "" LIB ${LIB})
+  endif()
+  string(STRIP ${LIB} LIB)
   # MPI_LIB is cached by find_library, but we don't want that.  Clear 
it first.
   set(MPI_LIB "MPI_LIB-NOTFOUND" CACHE FILEPATH "Cleared" FORCE)
   find_library(MPI_LIB NAMES ${LIB} HINTS ${MPI_LINK_PATH})
-- 
2.6.2.450.g259b5e6

-- 

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] Automoc same source - More thoughts

[Sebastian Holtermann]

These two hunks look like error checks added to the existing logic.
Please split these out into preceding commits with their own messages
explaining the new errors.  Please also include a

  Help/release/dev/automoc-diagnostics.rst

file with a release note explaining the new diagnostics.



Wow, this turned into a git learning session for me.
Git is as awesome as it is hard.

I've split the patch into three as suggested.

-Sebastian

>From 22f5af6aef69adc784287fb20357a98558966443 Mon Sep 17 00:00:00 2001
From: Sebastian Holtermann 
Date: Thu, 14 Apr 2016 18:30:30 +0200
Subject: [PATCH] AUTOMOC: moc file name collision check added.

AUTOMOC searches all source *.cpp files for moc include patterns of the
form #include .  If found the moc_NAME.cpp file will be
generated from the source's header as
${CMAKE_CURRENT_BINARY_DIR}/moc_NAME.cpp.
This allows the compiler to find the moc_NAME.cpp file regardless of the
location of NAME.cpp.
Now two NAME.cpp files in different directories (e.g. a/NAME.cpp, b/NAME.cpp)
would generate the same moc_NAME.cpp file effectively overwriting the other's
one.
A check to identify such name collisions was added.
---
 Help/release/dev/automoc-diagnostics.rst | 13 
 Source/cmQtAutoGenerators.cxx| 35 
 2 files changed, 48 insertions(+)
 create mode 100644 Help/release/dev/automoc-diagnostics.rst

diff --git a/Help/release/dev/automoc-diagnostics.rst b/Help/release/dev/automoc-diagnostics.rst
new file mode 100644
index 000..39a4872
--- /dev/null
+++ b/Help/release/dev/automoc-diagnostics.rst
@@ -0,0 +1,13 @@
+automoc-diagnostics
+--
+
+* AUTOMOC searches all source *.cpp files for moc include patterns of the
+  form #include .  If found the moc_NAME.cpp file will be
+  generated from the source's header as
+  ${CMAKE_CURRENT_BINARY_DIR}/moc_NAME.cpp.
+  This allows the compiler to find the moc_NAME.cpp file regardless of the
+  location of NAME.cpp.
+  Now two NAME.cpp files in different directories (e.g. a/NAME.cpp, b/NAME.cpp)
+  would generate the same moc_NAME.cpp file effectively overwriting the other's
+  one.
+  A check to identify such name collisions was added.
diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx
index ebe08b0..b2da918 100644
--- a/Source/cmQtAutoGenerators.cxx
+++ b/Source/cmQtAutoGenerators.cxx
@@ -99,6 +99,38 @@ static std::string extractSubDir(const std::string& absPath,
   return subDir;
 }
 
+/**
+ * Checks if the same value appears twice in the maps
+ */
+static void nameCollisionTest(
+const std::map& includedMocs,
+const std::map& notIncludedMocs )
+{
+  // Create new merged map
+  std::map mocMap ( includedMocs );
+  mocMap.insert ( notIncludedMocs.begin(), notIncludedMocs.end() );
+
+  // Look for value matches in merged map
+  typedef std::map::const_iterator Iter;
+  for ( Iter ait = mocMap.begin(); ait != mocMap.end(); ++ait )
+{
+for ( Iter bit = ++(Iter ( ait )); bit != mocMap.end(); ++bit )
+  {
+  if ( ait->second == bit->second )
+{
+std::cerr << "AUTOGEN: error: "
+ "The same moc file will be generated "
+ "from different sources." << std::endl
+  << "Rename one of the source files "
+ "to avoid this error." << std::endl
+  << ait->first << " -> " << ait->second << std::endl
+  << bit->first << " -> " << bit->second << std::endl;
+::exit(EXIT_FAILURE);
+}
+  }
+}
+}
+
 cmQtAutoGenerators::cmQtAutoGenerators()
 :Verbose(cmsys::SystemTools::GetEnv("VERBOSE") != 0)
 ,ColorOutput(true)
@@ -589,6 +621,9 @@ bool cmQtAutoGenerators::RunAutogen(cmMakefile* makefile)
   std::map notIncludedMocs;
   this->ParseHeaders(headerFiles, includedMocs, notIncludedMocs, includedUis);
 
+  // Lock for moc file name collisions
+  nameCollisionTest ( includedMocs, notIncludedMocs );
+
   // run moc on all the moc's that are #included in source files
   for(std::map::const_iterator
  it = includedMocs.begin();
-- 
2.8.0.rc3

>From 9959dd5c8146a3abde6a463ebc3b7fcf14e64f9c Mon Sep 17 00:00:00 2001
From: Sebastian Holtermann 
Date: Thu, 14 Apr 2016 20:01:04 +0200
Subject: [PATCH] AUTOMOC check for invalid moc file includes starting with ../
 added.

Moc file includes starting with .. would result in moc files beeing
generated in ${CMAKE_CURRENT_BINARY_DIR}/.. which is unsafe.
---
 Help/release/dev/automoc-diagnostics.rst |  4 
 Source/cmQtAutoGenerators.cxx| 15 +--
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/Help/release/dev/automoc-diagnostics.rst 

[CMake] (no subject)

[Abhijeet Mhatre via CMake]

http://bit.ly/1TOTr0m?675=bebenuci&991==33306881
-- 

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] Building a tool immediately so it can be used later in same CMake run

[Nagger]

Am 14.04.2016 um 14:17 schrieb Craig Scott:
Re-using the same build directory is a key part of the technique to 
avoid having to build the same thing twice.


A vague idea:
Use two different CMAKE_BINARY_DIRs but let the two mycompdir-targets 
use the same binary subdirectory.

(By using the 2nd parameter of add_subdirectory())


Marc


[1] https://cmake.org/cmake/help/v3.0/command/add_subdirectory.html



--

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.5.1-928-gee786ea

[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  ee786eaf3e502aeadc0e1b2913cf26fd0ec451a8 (commit)
   via  750594f10c68998f73aec24faccbee4fd1a3a59f (commit)
  from  273c68fe269b62f07081208763f77e7d2dbb8b5b (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=ee786eaf3e502aeadc0e1b2913cf26fd0ec451a8
commit ee786eaf3e502aeadc0e1b2913cf26fd0ec451a8
Merge: 273c68fe 750594f
Author: Brad King 
AuthorDate: Thu Apr 14 16:20:31 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Thu Apr 14 16:20:31 2016 -0400

Merge topic 'refactor-cmListFileBacktrace' into next

750594f1 Revert topic 'refactor-cmListFileBacktrace'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=750594f10c68998f73aec24faccbee4fd1a3a59f
commit 750594f10c68998f73aec24faccbee4fd1a3a59f
Author: Brad King 
AuthorDate: Thu Apr 14 16:19:41 2016 -0400
Commit: Brad King 
CommitDate: Thu Apr 14 16:19:41 2016 -0400

Revert topic 'refactor-cmListFileBacktrace'

It will be revised and restored.

diff --git a/Source/cmListFileCache.cxx b/Source/cmListFileCache.cxx
index f198ac3..d5d0184 100644
--- a/Source/cmListFileCache.cxx
+++ b/Source/cmListFileCache.cxx
@@ -400,40 +400,13 @@ bool cmListFileParser::AddArgument(cmListFileLexer_Token* 
token,
 
 cmListFileBacktrace::cmListFileBacktrace(cmState::Snapshot snapshot,
  cmCommandContext const& cc)
-  : Snapshot(snapshot)
+  : Context(cc)
+  , Snapshot(snapshot)
 {
-  if (!this->Snapshot.IsValid())
-{
-return;
-}
-
-  // Record the entire call stack now so that the `Snapshot` we
-  // save for later refers to a long-lived scope.  This avoids
-  // having to keep short-lived scopes around just to extract
-  // their backtrace information later.
-
-  cmListFileContext lfc =
-cmListFileContext::FromCommandContext(
-  cc, this->Snapshot.GetExecutionListFile());
-  this->push_back(lfc);
-
-  cmState::Snapshot parent = this->Snapshot.GetCallStackParent();
-  while (parent.IsValid())
+  if (this->Snapshot.IsValid())
 {
-lfc.Name = this->Snapshot.GetEntryPointCommand();
-lfc.Line = this->Snapshot.GetEntryPointLine();
-lfc.FilePath = parent.GetExecutionListFile();
-if (lfc.FilePath.empty())
-  {
-  break;
-  }
-this->push_back(lfc);
-
-this->Snapshot = parent;
-parent = parent.GetCallStackParent();
+this->Snapshot.Keep();
 }
-
-  this->Snapshot = this->Snapshot.GetCallStackBottom();
 }
 
 cmListFileBacktrace::~cmListFileBacktrace()
@@ -442,30 +415,48 @@ cmListFileBacktrace::~cmListFileBacktrace()
 
 void cmListFileBacktrace::PrintTitle(std::ostream& out) const
 {
-  if (this->empty())
+  if (!this->Snapshot.IsValid())
 {
 return;
 }
   cmOutputConverter converter(this->Snapshot);
-  cmListFileContext lfc = this->front();
+  cmListFileContext lfc =
+  cmListFileContext::FromCommandContext(
+this->Context, this->Snapshot.GetExecutionListFile());
   lfc.FilePath = converter.Convert(lfc.FilePath, cmOutputConverter::HOME);
   out << (lfc.Line ? " at " : " in ") << lfc;
 }
 
 void cmListFileBacktrace::PrintCallStack(std::ostream& out) const
 {
-  if (this->size() <= 1)
+  if (!this->Snapshot.IsValid())
+{
+return;
+}
+  cmState::Snapshot parent = this->Snapshot.GetCallStackParent();
+  if (!parent.IsValid() || parent.GetExecutionListFile().empty())
 {
 return;
 }
-  out << "Call Stack (most recent call first):\n";
 
   cmOutputConverter converter(this->Snapshot);
-  for (const_iterator i = this->begin() + 1; i != this->end(); ++i)
+  std::string commandName = this->Snapshot.GetEntryPointCommand();
+  long commandLine = this->Snapshot.GetEntryPointLine();
+
+  out << "Call Stack (most recent call first):\n";
+  while(parent.IsValid())
 {
-cmListFileContext lfc = *i;
-lfc.FilePath = converter.Convert(lfc.FilePath, cmOutputConverter::HOME);
+cmListFileContext lfc;
+lfc.Name = commandName;
+lfc.Line = commandLine;
+
+lfc.FilePath = converter.Convert(parent.GetExecutionListFile(),
+ cmOutputConverter::HOME);
 out << "  " << lfc << "\n";
+
+commandName = parent.GetEntryPointCommand();
+commandLine = parent.GetEntryPointLine();
+parent = parent.GetCallStackParent();
 }
 }
 
diff --git a/Source/cmListFileCache.h b/Source/cmListFileCache.h
index d3cab22..4d3055f 100644
--- a/Source/cmListFileCache.h
+++ b/Source/cmListFileCache.h
@@ -87,7 +87,7 @@ struct 

[cmake-developers] [CMake 0016064]: Missing /usr/local/bin causes --install script to fail.

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=16064 
== 
Reported By:Ho Cheung
Assigned To:
== 
Project:CMake
Issue ID:   16064
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-04-14 12:45 EDT
Last Modified:  2016-04-14 12:45 EDT
== 
Summary:Missing /usr/local/bin causes --install script to
fail.
Description: 
On a clean install of OSX 10.11.4, I discovered the install script fails to
create the symlinks:

Work-iMac:~ hocheung20$ sudo "/Applications/CMake.app/Contents/bin/cmake-gui"
--install
Failed: '/usr/local/bin/cmake' -> '/Applications/CMake.app/Contents/bin/cmake':
No such file or directory

This is because in a clean install of OSX, only /usr/local exists. When I mkdir
/usr/local/bin, the script succeeds.

Steps to Reproduce: 
Clean install OSX.
Copy CMake app to /Applications
sudo "/Applications/CMake.app/Contents/bin/cmake-gui" --install
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-04-14 12:45 Ho Cheung  New Issue
==

-- 

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] Automoc same source - More thoughts

[Brad King]

On 04/12/2016 03:12 PM, Sebastian Holtermann wrote:
> Here it is. Please review/commit.

Thanks.

> -subDir = absPath
> -  + cmsys::SystemTools::GetFilenamePath(currentMoc) + '/';
> +std::string fileNamePath = 
> cmsys::SystemTools::GetFilenamePath(currentMoc);
> +if ( fileNamePath.find ( ".." ) == std::string::npos )
> +  {
> +subDir = absPath + fileNamePath + '/';
> +  }
> +else
> +  {
> +  // We can't handle parent directories
> +  std::cerr << "AUTOGEN: error: moc include \"" << currentMoc
> +<< "\" contains parent directory reference \"..\""
> +<< std::endl;
> +  ::exit(EXIT_FAILURE);
> +  }
[snip]
> +  // Check: Look for name collisions
> +{
> +typedef std::map::const_iterator Iter;
> +for ( Iter ita = includedMocs.begin(); ita != includedMocs.end(); ++ita )
> +  {
> +  Iter itb = ita;
> +  ++itb;
> +  for ( ; itb != includedMocs.end(); ++itb )
> +{
> +if ( ita->second == itb->second )
> +  {
> +  std::cerr << "AUTOGEN: error: moc name collision" << std::endl
> +<< ita->first << " -> " << ita->second << std::endl
> +<< itb->first << " -> " << itb->second << std::endl;
> +  ::exit(EXIT_FAILURE);
> +  }
> +}
> +  }
> +}
> +

These two hunks look like error checks added to the existing logic.
Please split these out into preceding commits with their own messages
explaining the new errors.  Please also include a

 Help/release/dev/automoc-diagnostics.rst

file with a release note explaining the new diagnostics.

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] c++11 feature and cmake feature name mapping

[Nicholas Braden]

I don't think CMake can yet detect features of the standard library
implementation, only features of the language. One compiler may
support more features than another compiler which supports more of the
standard library, and in some cases the same compiler can support two
or more different standard libraries. I think you're better off
requesting the language standard you want directly with CXX_STANDARD.

On Thu, Apr 14, 2016 at 7:05 AM, Xi Shen  wrote:
> Hi,
>
> I know we should use [target_compile_features][1] to enable c++11 features
> in cmake. And I also found the [descriptions][2] about the features.
>
> In my code I used the `random_device`, `default_random_engine` and
> `uniform_int_distribution` which are a new features, but I could not find a
> matching feature in the description.
>
>
> [1]: https://cmake.org/cmake/help/v3.1/command/target_compile_features.html
> [2]:
> https://cmake.org/cmake/help/v3.1/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html#prop_gbl:CMAKE_CXX_KNOWN_FEATURES
>
> Thanks,
> David
>
> --
>
> Regards,
> David
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Building a tool immediately so it can be used later in same CMake run

[Craig Scott]

Sorry, forgot to follow up on this response. Re-using the same build
directory is a key part of the technique to avoid having to build the same
thing twice. So far, the only real problem I've seen is that the Xcode
generator is potentially less suited to this arrangement in that it seems
very hard to avoid building it twice even when using the same build
directory. It all still works, just not necessarily as efficiently as I
think it could. Haven't had time to delve deeper into the Xcode side yet to
investigate further.

The install targets option sounds like a good suggestion. I might play with
that in the coming months. Cheers.


On Sun, Apr 3, 2016 at 2:09 AM, Tamás Kenéz  wrote:

> Craig,
>
> I'm sorry for my previous answer which I wrote in haste. Now I've read
> your SO post and realized the question is a bit more complex then "is
> execute_process safe instead of ExternalProject".
>
> Anyway I still think your approach is basically correct. I have the
> following comments:
>
> - I wouldn't re-use the current build dir and would build mycomp always in
> it's own build dir. Also, I'd always use the plain default cmake generator
> (which is a must when crosscompiling anyway). No need to forward any
> settings to it from the superbuild. Also, I'd always build the Release
> config for mycomp.
>
> - You could "install(TARGETS mycomp DESTINATION bin)" in your EARLY_BUILD
> then later use "find_program(mycomp_EXECUTABLE mycomp ...) later to save
> guessing the executable's name.
>
> Tamas
>
> On Fri, Apr 1, 2016 at 9:25 PM, Tamás Kenéz  wrote:
>
>> Craig,
>>
>> My cmake-based build system in my company's CI framework works exactly
>> that way: there's a generic cmake script[1] (invoked with cmake -P) that
>> reads in a file which contains repo-urls and build parameters for 50+
>> projects and builds them for 3 platforms (linux, win, mac) 5 compilers
>> (cross-compilers, too) invoking child cmake builds with execute_process.
>> This is done after each push and one daily clean build.
>>
>> I've never had any problems with that approach.
>>
>> On the other hand, the system was originally designed with
>> ExternalProject and I had many problems.
>>
>> [1]: https://github.com/tamaskenez/centralbuilder
>>
>> Tamas
>>
>>
>>
>> On Fri, Apr 1, 2016 at 1:53 AM, Craig Scott 
>> wrote:
>>
>>> All,
>>>
>>> I originally planned to ask this question directly on this mailing list,
>>> but it got a bit more involved, so I posted it to stackoverflow instead.
>>> I'm interested if anyone can shed some more authoritative light on the
>>> proposed method for the following question:
>>>
>>> http://stackoverflow.com/q/36084785/1938798
>>>
>>> *Short version*: invoke a nested cmake-and-build immediately within the
>>> main CMake run to build a specific target via execute_process(). This makes
>>> that tool available for use still within the same (main) CMake run. An
>>> ExternalProject-based technique would normally be a better solution, but in
>>> this particular case, that wasn't possible.
>>>
>>> I'd be interested if anyone can confirm whether the suggested approach
>>> is guaranteed to be safe for all generators and platforms, or whether there
>>> are other factors I have not considered in the proposed technique.
>>>
>>> Cheers
>>>
>>> --
>>> Craig Scott
>>> Melbourne, Australia
>>> http://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
>>>
>>
>>
>


-- 
Craig Scott
Melbourne, Australia
http://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] c++11 feature and cmake feature name mapping

[Craig Scott]

There are pros and cons to specifying individual compiler features compared
to just specifying a C++ standard overall. It depends somewhat on what else
you have to link in. For example, if you link to a third party library
built with C++11 settings, you will have to link in that same library to
avoid mismatched runtime library problems. More details in one of my blog
articles about this here:

https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/



On Thu, Apr 14, 2016 at 10:05 PM, Xi Shen  wrote:

> Hi,
>
> I know we should use [target_compile_features][1] to enable c++11 features
> in cmake. And I also found the [descriptions][2] about the features.
>
> In my code I used the `random_device`, `default_random_engine` and
> `uniform_int_distribution` which are a new features, but I could not find a
> matching feature in the description.
>
>
> [1]:
> https://cmake.org/cmake/help/v3.1/command/target_compile_features.html
> [2]:
> https://cmake.org/cmake/help/v3.1/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html#prop_gbl:CMAKE_CXX_KNOWN_FEATURES
>
> Thanks,
> David
>
> --
>
> Regards,
> David
>
> --
>
> 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
http://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] How to deal with generated source files (w/ dependency tracking) for globs

[Craig Scott]

It's not quite your situation, but it may have some common elements and the
general idea may get you thinking about what might work for you. This
question/answer I asked this list about last week:

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

We've been using this approach with success on all the platforms listed
there. In your case, you may want to consider getting your tool that
converts from Nim to C to do that off to the side and only replace the
existing generated C sources with the new ones if they are different.
That's what our particular tool in the above linked article does and it
works rather well for us all as part of one single build. I haven't tried
building within Xcode directly, but we do have scripted builds for iOS
using the Xcode generator which are working.




On Thu, Apr 14, 2016 at 8:40 PM, Eric Wing  wrote:

> On 4/6/16, iosif neitzke  wrote:
> > I think it depends on when you want the output files from Nim
> > generated and which files are the most frequently developed.
> > If it is usually a one-time generation per clean development session,
> > the simplest case, where the *.NIM source files are not the files
> > most likely to be changed, I would think execute_process should
> > work okay?
> >
>
> Thanks for the responses. In this case, the common use case would be
> writing/changing the NIM files, which in turn require the C files to
> be rewritten. (The users are writing in NIM, and C generation to them
> is just an implementation detail and means to an end.)
>
> It sounds like this is going to be a pain.
>
> I appreciate everybody's responses on this.
>
> Thanks,
> Eric
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>



-- 
Craig Scott
Melbourne, Australia
http://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] c++11 feature and cmake feature name mapping

[Xi Shen]

Hi,

I know we should use [target_compile_features][1] to enable c++11 features
in cmake. And I also found the [descriptions][2] about the features.

In my code I used the `random_device`, `default_random_engine` and
`uniform_int_distribution` which are a new features, but I could not find a
matching feature in the description.


[1]: https://cmake.org/cmake/help/v3.1/command/target_compile_features.html
[2]:
https://cmake.org/cmake/help/v3.1/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html#prop_gbl:CMAKE_CXX_KNOWN_FEATURES

Thanks,
David

-- 

Regards,
David
-- 

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] How to deal with generated source files (w/ dependency tracking) for globs

[Eric Wing]

On 4/6/16, iosif neitzke  wrote:
> I think it depends on when you want the output files from Nim
> generated and which files are the most frequently developed.
> If it is usually a one-time generation per clean development session,
> the simplest case, where the *.NIM source files are not the files
> most likely to be changed, I would think execute_process should
> work okay?
>

Thanks for the responses. In this case, the common use case would be
writing/changing the NIM files, which in turn require the C files to
be rewritten. (The users are writing in NIM, and C generation to them
is just an implementation detail and means to an end.)

It sounds like this is going to be a pain.

I appreciate everybody's responses on this.

Thanks,
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0016063]: Wrong protobuf search logic

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=16063 
== 
Reported By:xseven
Assigned To:
== 
Project:CMake
Issue ID:   16063
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-04-14 04:40 EDT
Last Modified:  2016-04-14 04:40 EDT
== 
Summary:Wrong protobuf search logic
Description: 
I faced a problem with using find_package(Protobuf).

I'm using protobuf-3.0.0-beta-2

I built it and installed via MSVC 2015 but module looks for 
${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug)and Release
which seem missing in contemporary MSVC build anymore

Could be more reasonable to use PROTOBUF_SRC_ROOT_FOLDER as a path to installed
protobuf files after build?

Steps to Reproduce: 
Build protobuf-3.0.0-beta-2
Set PROTOBUF_SRC_ROOT_FOLDER run CMake 3.5.1
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-04-14 04:40 xseven New Issue
==

-- 

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] Automoc same source - More thoughts

[Sebastian Holtermann]

Am 13.04.2016 um 16:40 schrieb Brad King:

On 04/13/2016 10:08 AM, Sebastian Holtermann wrote:

Well, looking into the sources and there is already Tests/QtAutogen.
It covers various #include "moc_..." cases.


Perhaps, but as pointed out in the issue tracker entry I linked those
test cases were not sufficient to fail after the the incorrect fix
made and reverted there.  Please identify why and extend them.


Now after testing it I think the incorrect fix was not incorrect at all.
The feared moc renaming was only applied to mocs that were not #included.

For not #included mocs the (not so) incorrect pach creates long moc 
names in this format: moc_DIRNAME_BASENAME.cpp.


My patch creates the not #included mocs in subdirectories.
This is more robust IMO.

-Sebastian

--

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