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

[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