date:20170215

Re: [CMake] Disabling INSTALL target for subdirectory

2017-02-15 Thread Craig Scott

You can use the COMPONENT option to install() for your own project and then
select a component-based package if you are packaging with CPack. We
currently do this with builds that incorporate other projects with
add_subdirectory() similar to your case.

If you are using install as a build target (ie make install or equivalent),
I don't think the above will help you. I don't recall if the
EXCLUDE_FROM_ALL option to add_subdirectory() affects install or not. I
believe there was some discussion about this in one of the mailing lists or
gitlab issues recently, so maybe someone else can chime in to clarify this
part.


On Thu, 16 Feb 2017 at 3:59 pm, Milan Ziegler  wrote:

> Hi,
>
> we are using the CMake install mechanism "install(...)" to copy all
> relevant files and target binaries of the product into the CMake install
> prefix folder, for further packaging. So far so good.
>
> We are also using several thirdparty libraries, hosting them inside our
> own repository and building them along with our own code, usually using
> add_subdirectory utilizing their native CMake buildsystem.
>
> Turns out, other developers also like the CMake install mechanism.
>
> So now the INSTALL target of our whole project also installs thirdparty
> components, which we do not want to deliver with our own product (think
> static libraries, which are already linked into our executable).
>
> After a lot of googling, here's my question: Is there a clean way to
> disable the install target for a subdirectory _without_ also disabling
> it completely for the remaining project?
>
> What we already tried:
> * Setting CMAKE_INSTALL_PREFIX to a temporary directory for the
> subdirectory (doesn't work)
> * "function(install) endfunction()" to disable the install function for
> the subdirectory (breaks CMake in hilarious ways)
>
> What we now do:
> Using a custom target, we patch the cmake_install.cmake files in the
> build directories before installing (works, but it's an  abomination of
> a hack)
>
> Any help? I think it's a valid usecase for CMake but there doesn't seem
> to be an easy way to do it.
>
> We are using CMake 3.5.
>
>
> Thank you :)
>
> --
>   Milan
>   mi...@fastmail.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
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] Disabling INSTALL target for subdirectory

2017-02-15 Thread Konstantin Podsvirov

Hello all!10:00, 16 February 2017 г., Milan Ziegler :Hi,we are using the CMake install mechanism "install(...)" to copy allrelevant files and target binaries of the product into the CMake installprefix folder, for further packaging. So far so good.We are also using several thirdparty libraries, hosting them inside ourown repository and building them along with our own code, usually usingadd_subdirectory utilizing their native CMake buildsystem.Turns out, other developers also like the CMake install mechanism.So now the INSTALL target of our whole project also installs thirdpartycomponents, which we do not want to deliver with our own product (thinkstatic libraries, which are already linked into our executable).After a lot of googling, here's my question: Is there a clean way todisable the install target for a subdirectory _without_ also disablingit completely for the remaining project?What we already tried:* Setting CMAKE_INSTALL_PREFIX to a temporary directory for thesubdirectory (doesn't work)* "function(install) endfunction()" to disable the install function forthe subdirectory (breaks CMake in hilarious ways)What we now do:Using a custom target, we patch the cmake_install.cmake files in thebuild directories before installing (works, but it's an  abomination ofa hack)Any help? I think it's a valid usecase for CMake but there doesn't seemto be an easy way to do it.We are using CMake 3.5.Thank you :)--   Milan  mi...@fastmail.com-- Powered by www.kitware.comPlease keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQKitware offers various services to support the CMake community. For more information on each offering, please visit:CMake Support: http://cmake.org/cmake/help/support.htmlCMake Consulting: http://cmake.org/cmake/help/consulting.htmlCMake Training Courses: http://cmake.org/cmake/help/training.htmlVisit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.htmlFollow this link to subscribe/unsubscribe:http://public.kitware.com/mailman/listinfo/cmakeIt common actual problem.My suggestion:a) Separate CMakeLists.txt code to several files: - CMakeLists.txt; - CTestLists.txt; - CDashLists.txt; - CPackLists.txt;b) Add common options to enable/disable feature for directory: - CMAKE_LISTS_TXT:BOOL; - CTEST_LISTS_TXT:BOOL; - CDASH_LISTS_TXT:BOOL; - CPACK_LISTS_TXT:BOOL;c) Fix add_subdirectory command implementation :-)--Regards,Konstantin Podsvirov
-- 

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] Disabling INSTALL target for subdirectory

2017-02-15 Thread Milan Ziegler

Hi,

we are using the CMake install mechanism "install(...)" to copy all
relevant files and target binaries of the product into the CMake install
prefix folder, for further packaging. So far so good.

We are also using several thirdparty libraries, hosting them inside our
own repository and building them along with our own code, usually using
add_subdirectory utilizing their native CMake buildsystem.

Turns out, other developers also like the CMake install mechanism.

So now the INSTALL target of our whole project also installs thirdparty
components, which we do not want to deliver with our own product (think
static libraries, which are already linked into our executable).

After a lot of googling, here's my question: Is there a clean way to
disable the install target for a subdirectory _without_ also disabling
it completely for the remaining project?

What we already tried:
* Setting CMAKE_INSTALL_PREFIX to a temporary directory for the
subdirectory (doesn't work)
* "function(install) endfunction()" to disable the install function for
the subdirectory (breaks CMake in hilarious ways)

What we now do:
Using a custom target, we patch the cmake_install.cmake files in the
build directories before installing (works, but it's an  abomination of
a hack)

Any help? I think it's a valid usecase for CMake but there doesn't seem
to be an easy way to do it.

We are using CMake 3.5.


Thank you :)

--
  Milan
  mi...@fastmail.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-commits] CMake branch, master, updated. v3.8.0-rc1-103-gb922994

2017-02-15 Thread 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  b9229944cf1b9f27e1fc97921e736ca17fc4eb0c (commit)
  from  72cfb3c3d2e8f6167cf08289691f7b0c61d0d331 (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=b9229944cf1b9f27e1fc97921e736ca17fc4eb0c
commit b9229944cf1b9f27e1fc97921e736ca17fc4eb0c
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Thu Feb 16 00:01:10 2017 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Thu Feb 16 00:01:10 2017 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 2efc5bf..a92cb20 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 8)
-set(CMake_VERSION_PATCH 20170215)
+set(CMake_VERSION_PATCH 20170216)
 #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] Errors from CDash

2017-02-15 Thread Thompson, KT

When I run

php5 autoRemoveBuilds.php all

for my cdash 2.2.3 installation, I see the following errors (and old builds are 
not removed):

removing builds for all
  -- removing old buildids for projectid: 2
PHP Warning:  mysql_fetch_array() expects parameter 1 to be resource, boolean g8
PHP Warning:  mysql_fetch_array() expects parameter 1 to be resource, boolean g8
MySQL server has gone awaySQL error in remove_build():MySQL server has gone awa8
  -- removing old buildids for projectid: 2
PHP Warning:  mysql_fetch_array() expects parameter 1 to be resource, boolean g8
  -- removing old buildids for projectid: 3
MySQL server has gone awaySQL error in dailyupdates::removeFirstBuilds():MySQL 8
 -- removing old buildids for projectid: 7
PHP Warning:  mysql_fetch_array() expects parameter 1 to be resource, boolean g8
  -- removing old buildids for projectid: 7
MySQL server has gone awaySQL error in dailyupdates::removeFirstBuilds():MySQL 8
  -- removing old buildids for projectid: 8
PHP Warning:  mysql_fetch_array() expects parameter 1 to be resource, boolean g8
  -- removing old buildids for projectid: 8
MySQL server has gone awaySQL error in dailyupdates::removeFirstBuilds():MySQL 8
  -- removing old buildids for projectid: 9
PHP Warning:  mysql_fetch_array() expects parameter 1 to be resource, boolean g8
  -- removing old buildids for projectid: 9
MySQL server has gone awaySQL error in dailyupdates::removeFirstBuilds():MySQL 8
  -- removing old buildids for projectid: 10
PHP Warning:  mysql_fetch_array() expects parameter 1 to be resource, boolean g8
  -- removing old buildids for projectid: 10

Does this make sense to any of you?  How should I prune old builds from my 
database?

-kt
-- 

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.8.0-rc1-192-ge080ad3

2017-02-15 Thread 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  e080ad36397d6b7d813b3b1c26a78414858c668a (commit)
   via  28ee3784055ab6b21563d56024b1324c16949cbc (commit)
  from  37537d95cbcb3e7265599523bd31fe13cef25654 (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=e080ad36397d6b7d813b3b1c26a78414858c668a
commit e080ad36397d6b7d813b3b1c26a78414858c668a
Merge: 37537d9 28ee378
Author: Brad King 
AuthorDate: Wed Feb 15 15:19:25 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 15 15:19:25 2017 -0500

Merge topic 'autogen_fix_3.8' into next

28ee3784 Autogen: Fix headers not skipped


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=28ee3784055ab6b21563d56024b1324c16949cbc
commit 28ee3784055ab6b21563d56024b1324c16949cbc
Author: Sebastian Holtermann 
AuthorDate: Wed Feb 15 21:00:39 2017 +0100
Commit: Sebastian Holtermann 
CommitDate: Wed Feb 15 21:00:39 2017 +0100

Autogen: Fix headers not skipped

diff --git a/Source/cmQtAutoGenerators.cxx b/Source/cmQtAutoGenerators.cxx
index c84fe4f..1d6972b 100644
--- a/Source/cmQtAutoGenerators.cxx
+++ b/Source/cmQtAutoGenerators.cxx
@@ -655,10 +655,10 @@ bool cmQtAutoGenerators::RunAutogen(cmMakefile* makefile)
it != this->Headers.end(); ++it) {
 const std::string& headerName = *it;
 if (!this->MocSkipTest(headerName)) {
-  headerFilesMoc.insert(this->Headers.begin(), this->Headers.end());
+  headerFilesMoc.insert(headerName);
 }
 if (!this->UicSkipTest(headerName)) {
-  headerFilesUic.insert(this->Headers.begin(), this->Headers.end());
+  headerFilesUic.insert(headerName);
 }
   }
   this->ParseHeaders(headerFilesMoc, headerFilesUic, includedMocs,

---

Summary of changes:
 Source/cmQtAutoGenerators.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.8.0-rc1-190-g37537d9

2017-02-15 Thread 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  37537d95cbcb3e7265599523bd31fe13cef25654 (commit)
   via  ac0962cead1db76b44cbb9d9a413956ca31a7982 (commit)
  from  2556769b73a707529a73df5a474620281e3fb7d8 (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=37537d95cbcb3e7265599523bd31fe13cef25654
commit 37537d95cbcb3e7265599523bd31fe13cef25654
Merge: 2556769 ac0962c
Author: Brad King 
AuthorDate: Wed Feb 15 15:12:22 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 15 15:12:22 2017 -0500

Merge topic 'TestBigEndian-cxx-only' into next

ac0962ce TestBigEndian: Fix to work with CXX without C


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ac0962cead1db76b44cbb9d9a413956ca31a7982
commit ac0962cead1db76b44cbb9d9a413956ca31a7982
Author: Uwe Koloska 
AuthorDate: Wed Feb 15 18:21:35 2017 +0100
Commit: Brad King 
CommitDate: Wed Feb 15 15:08:37 2017 -0500

TestBigEndian: Fix to work with CXX without C

diff --git a/Modules/TestBigEndian.cmake b/Modules/TestBigEndian.cmake
index 085be22..cc627d0 100644
--- a/Modules/TestBigEndian.cmake
+++ b/Modules/TestBigEndian.cmake
@@ -19,21 +19,29 @@ macro(TEST_BIG_ENDIAN VARIABLE)
 message(STATUS "Check if the system is big endian")
 message(STATUS "Searching 16 bit integer")
 
+if(CMAKE_C_COMPILER_LOADED)
+  set(_test_language "C")
+elseif(CMAKE_CXX_COMPILER_LOADED)
+  set(_test_language "CXX")
+else()
+  message(FATAL_ERROR "TEST_BIG_ENDIAN needs either C or CXX language 
enabled")
+endif()
+
 include(CheckTypeSize)
 
-CHECK_TYPE_SIZE("unsigned short" CMAKE_SIZEOF_UNSIGNED_SHORT)
+CHECK_TYPE_SIZE("unsigned short" CMAKE_SIZEOF_UNSIGNED_SHORT LANGUAGE 
${_test_language})
 if(CMAKE_SIZEOF_UNSIGNED_SHORT EQUAL 2)
   message(STATUS "Using unsigned short")
   set(CMAKE_16BIT_TYPE "unsigned short")
 else()
-  CHECK_TYPE_SIZE("unsigned int"   CMAKE_SIZEOF_UNSIGNED_INT)
+  CHECK_TYPE_SIZE("unsigned int"   CMAKE_SIZEOF_UNSIGNED_INT LANGUAGE 
${_test_language})
   if(CMAKE_SIZEOF_UNSIGNED_INT)
 message(STATUS "Using unsigned int")
 set(CMAKE_16BIT_TYPE "unsigned int")
 
   else()
 
-CHECK_TYPE_SIZE("unsigned long"  CMAKE_SIZEOF_UNSIGNED_LONG)
+CHECK_TYPE_SIZE("unsigned long"  CMAKE_SIZEOF_UNSIGNED_LONG LANGUAGE 
${_test_language})
 if(CMAKE_SIZEOF_UNSIGNED_LONG)
   message(STATUS "Using unsigned long")
   set(CMAKE_16BIT_TYPE "unsigned long")
@@ -45,17 +53,21 @@ macro(TEST_BIG_ENDIAN VARIABLE)
 
 endif()
 
+if(_test_language STREQUAL "CXX")
+  set(_test_file 
"${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/TestEndianess.cpp")
+else()
+  set(_test_file 
"${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/TestEndianess.c")
+endif()
 
 configure_file("${CMAKE_ROOT}/Modules/TestEndianess.c.in"
-   
"${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/TestEndianess.c"
+   ${_test_file}
@ONLY)
 
- file(READ 
"${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/TestEndianess.c"
-  TEST_ENDIANESS_FILE_CONTENT)
+ file(READ ${_test_file} TEST_ENDIANESS_FILE_CONTENT)
 
  try_compile(HAVE_${VARIABLE}
   "${CMAKE_BINARY_DIR}"
-  "${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/TestEndianess.c"
+  ${_test_file}
   OUTPUT_VARIABLE OUTPUT
   COPY_FILE 
"${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/TestEndianess.bin" )
 

---

Summary of changes:
 Modules/TestBigEndian.cmake |   26 +++---
 1 file changed, 19 insertions(+), 7 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.8.0-rc1-188-g2556769

2017-02-15 Thread 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  2556769b73a707529a73df5a474620281e3fb7d8 (commit)
   via  109b8a6fd32be9886de71f98170e0c512ac9883f (commit)
   via  bd5ea6993c8376cd3612100019e15ee256a758d8 (commit)
   via  3936a2886efc1fd46560352f3a48d6a656f95367 (commit)
  from  dd0648f5baa4a6ddf640191fb9c82fc300c3732b (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=2556769b73a707529a73df5a474620281e3fb7d8
commit 2556769b73a707529a73df5a474620281e3fb7d8
Merge: dd0648f 109b8a6
Author: Brad King 
AuthorDate: Wed Feb 15 15:03:42 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 15 15:03:42 2017 -0500

Merge topic 'vs-refactor-unknown-flags' into next

109b8a6f VS: Refactor AdditionalOptions generation
bd5ea699 cmVisualStudioGeneratorOptions: Add PrependInerhitedString method
3936a288 cmIDEOptions: Add SpaceAppendable flag table type


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=109b8a6fd32be9886de71f98170e0c512ac9883f
commit 109b8a6fd32be9886de71f98170e0c512ac9883f
Author: Brad King 
AuthorDate: Wed Feb 15 10:40:00 2017 -0500
Commit: Brad King 
CommitDate: Wed Feb 15 10:41:36 2017 -0500

VS: Refactor AdditionalOptions generation

Store unknown flags directly in a flag map entry for `AdditionalOptions`
instead of having a separate member for them.  This avoids duplicating
the output generation logic for the entry.

diff --git a/Source/cmIDEOptions.h b/Source/cmIDEOptions.h
index aaa9d3d..465cf2c 100644
--- a/Source/cmIDEOptions.h
+++ b/Source/cmIDEOptions.h
@@ -74,9 +74,6 @@ protected:
   // Preprocessor definitions.
   std::vector Defines;
 
-  // Unrecognized flags that get no special handling.
-  std::string FlagString;
-
   bool DoingDefine;
   bool AllowDefine;
   bool AllowSlash;
diff --git a/Source/cmLocalVisualStudio7Generator.cxx 
b/Source/cmLocalVisualStudio7Generator.cxx
index 38dda04..6e976e1 100644
--- a/Source/cmLocalVisualStudio7Generator.cxx
+++ b/Source/cmLocalVisualStudio7Generator.cxx
@@ -787,7 +787,6 @@ void cmLocalVisualStudio7Generator::WriteConfiguration(
  << this->ConvertToXMLOutputPath(modDir.c_str())
  << "\\$(ConfigurationName)\"\n";
   }
-  targetOptions.OutputAdditionalOptions(fout, "\t\t\t\t", "\n");
   fout << "\t\t\t\tAdditionalIncludeDirectories=\"";
   std::vector includes;
   this->GetIncludeDirectories(includes, target, "C", configName);
@@ -1090,7 +1089,6 @@ void cmLocalVisualStudio7Generator::OutputBuildTool(
   if (!gg->NeedLinkLibraryDependencies(target)) {
 fout << "\t\t\t\tLinkLibraryDependencies=\"false\"\n";
   }
-  linkOptions.OutputAdditionalOptions(fout, "\t\t\t\t", "\n");
   // Use the NOINHERIT macro to avoid getting VS project default
   // libraries which may be set by the user to something bad.
   fout << "\t\t\t\tAdditionalDependencies=\"$(NOINHERIT) "
@@ -1176,7 +1174,6 @@ void cmLocalVisualStudio7Generator::OutputBuildTool(
   if (!gg->NeedLinkLibraryDependencies(target)) {
 fout << "\t\t\t\tLinkLibraryDependencies=\"false\"\n";
   }
-  linkOptions.OutputAdditionalOptions(fout, "\t\t\t\t", "\n");
   // Use the NOINHERIT macro to avoid getting VS project default
   // libraries which may be set by the user to something bad.
   fout << "\t\t\t\tAdditionalDependencies=\"$(NOINHERIT) "
@@ -1675,7 +1672,6 @@ bool cmLocalVisualStudio7Generator::WriteGroup(
 fileOptions.Parse(fc.CompileFlags.c_str());
 fileOptions.AddDefines(fc.CompileDefs.c_str());
 fileOptions.AddDefines(fc.CompileDefsConfig.c_str());
-fileOptions.OutputAdditionalOptions(fout, "\t\t\t\t\t", "\n");
 fileOptions.OutputFlagMap(fout, "\t\t\t\t\t");
 fileOptions.OutputPreprocessorDefinitions(fout, "\t\t\t\t\t", "\n",
   ppLang);
diff --git a/Source/cmVisualStudio10TargetGenerator.cxx 
b/Source/cmVisualStudio10TargetGenerator.cxx
index f084e19..e3853ed 100644
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@ -1939,7 +1939,7 @@ bool 
cmVisualStudio10TargetGenerator::OutputSourceSpecificFlags(
   }
   clOptions.AddDefines(configDefines.c_str());
   clOptions.SetConfiguration((*config).c_str());
-  clOptions.OutputAdditionalOptions(*this->BuildFileStream, "  ", "");
+  clOptions.PrependInheritedString("AdditionalOptions");

[Cmake-commits] CMake branch, next, updated. v3.8.0-rc1-184-gdd0648f

2017-02-15 Thread 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  dd0648f5baa4a6ddf640191fb9c82fc300c3732b (commit)
   via  51849bbab8b1b6b8299dc08e98ca1524cc1e168a (commit)
  from  b0ea076370600cd3e6a5d04a90667c0d2a8e4727 (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=dd0648f5baa4a6ddf640191fb9c82fc300c3732b
commit dd0648f5baa4a6ddf640191fb9c82fc300c3732b
Merge: b0ea076 51849bb
Author: Brad King 
AuthorDate: Wed Feb 15 15:00:55 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 15 15:00:55 2017 -0500

Merge topic 'fix-ctest_update-svn' into next

51849bba ctest_update: Fix svn log and external loading


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=51849bbab8b1b6b8299dc08e98ca1524cc1e168a
commit 51849bbab8b1b6b8299dc08e98ca1524cc1e168a
Author: Brad King 
AuthorDate: Wed Feb 15 13:43:34 2017 -0500
Commit: Brad King 
CommitDate: Wed Feb 15 14:44:37 2017 -0500

ctest_update: Fix svn log and external loading

Since commit v3.7.0-rc1~132^2 (CTestSVN: Fix segfault when
CTEST_UPDATE_VERSION_ONLY is enabled, 2016-09-12) we do not properly
extract svn log or externals.  After updating we erase the information
that was loaded before updating and can no longer log the changes
between revisions to extract authors.

Fix this by only loading the repository information once, whether needed
by `NoteOldRevision`, `NoteNewRevision`, or both.

Fixes: #12630, #16646

diff --git a/Source/CTest/cmCTestSVN.cxx b/Source/CTest/cmCTestSVN.cxx
index fc405ca..410e0d4 100644
--- a/Source/CTest/cmCTestSVN.cxx
+++ b/Source/CTest/cmCTestSVN.cxx
@@ -523,8 +523,11 @@ private:
 
 void cmCTestSVN::LoadRepositories()
 {
+  if (!this->Repositories.empty()) {
+return;
+  }
+
   // Info for root repository
-  this->Repositories.clear();
   this->Repositories.push_back(SVNInfo(""));
   this->RootInfo = &(this->Repositories.back());
 

---

Summary of changes:
 Source/CTest/cmCTestSVN.cxx |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)


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

Re: [CMake] cmake 3.7.2 centos 7 :: kwsys.testSystemTools (Failed)

2017-02-15 Thread Chuck Atkins

Hi Adrian,

So, would this imply that cmake is not supported on EL7 because gcc does
> not support cxx11 ?
>

That's not really what's happening.  CMake is testing the C compiler to
determine whether or not it supports C11 features and the C++ compiler to
see if it supports C++11.  The error messages are expected in many of the
test cases.  Here it's jsut checking to see if what it knows about the
features supported by the specific version of GCC line up correctly with
reality.  i.e. CMake thinks that gcc 4.8.2 supports certain features so it
tests them to make sure.  So it's not saying that CMake isn't supported,
just that the 1 specific test failed for some reason.



> So, does anyone have any idea what is the latest 3.x version that can be
> built on centos 7?
>

All that being said, I wasn't able to reproduce the error with the current
3.7.2 release:

[chuck.atkins@deepthought v3.7.2]$ lsb_release -d
Description:CentOS Linux release 7.3.1611 (Core)
[chuck.atkins@deepthought v3.7.2]$ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
...
[chuck.atkins@deepthought v3.7.2]$ ../../source/v3.7.2/bootstrap
--parallel=28
...
CMake has bootstrapped.  Now run gmake.
[chuck.atkins@deepthought v3.7.2]$ make -j28
...
100%] Built target ctest
[chuck.atkins@deepthought v3.7.2]$ ./bin/ctest -j 28
...
100% tests passed, 0 tests failed out of 431

Label Time Summary:
Label1=   0.51 sec (1 test)
Label2=   0.51 sec (1 test)

Total Test time (real) = 247.03 sec
[chuck.atkins@deepthought v3.7.2]$

What specific versionof EL7 are you running and which version of GCC?

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
-- 

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

2017-02-15 Thread Konstantin Tokarev



15.02.2017, 20:08, "Bill Newcomb" :
> My top-level CMakeLists.txt files always end up with a lot of
>
> if(NOT_DEFINED foo)
>  set(foo bar)
> endif()
>
> things to allow people to pass interesting things on the command line or
> to write their own "set this and that" CMakeLists.txt and include the
> top-level one.
>
> It would improve readability to have set_if_not_set and friends from
> CTest.cmake available in a separate module or, better still, as language
> primitives, either as-is or like
>
> set(IF_NOT_SET foo bar)
>
> or maybe
>
> set(foo bar IF_NOT_SET)
>
> Obviously I could define set_if_not_set at the top of each top-level
> CMakeLists.txt, but the above would be nicer.
>
> What do you think?

Use options or CACHE variables, default values will be set unless user 
specifies them
explicitly.

>
> Thanks,
> B.
>
> ---
> This email message is for the sole use of the intended recipient(s) and may 
> contain
> confidential information. Any unauthorized review, use, disclosure or 
> distribution
> is prohibited. If you are not the intended recipient, please contact the 
> sender by
> reply email and destroy all copies of the original message.
> ---
> --
>
> 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

-- 
Regards,
Konstantin
-- 

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] Problem with override file ...

2017-02-15 Thread Michael Burns via CMake


  
  
I found that changing the add_definitions lines to
set(CMAKE_C_FLAGS_INIT ...) or set(CMAKE_CXX_FLAGS_INIT ...)
resolved the issue. I have not found documentation anywhere that
says "this is how it must be done".

So, is this the expected behavior when using add_definitions in an
override file?

Mike


On 2/8/2017 11:50 AM, Michael Burns via
  CMake wrote:


  Using the following override file results in the try_compile failing for
both the C compiler and the C++ compiler. The output shows that the
override file is being processed multiple times. The first time it is
processed, the variable PARAM is 'set' as specified on the CMake command
line. However, subsequent processing of the file shows that PARAM is not
'set' and results in the 'bogus-option' being added to the compiler
command line. This, of course, results in the try_compile's failing.

message(STATUS "Processing override_compiler_flags.cmake ...")

if(CMAKE_COMPILER_IS_GNUCC OR CMAKE_COMPILER_IS_GNUCXX)
if(PARAM STREQUAL "set")
message(AUTHOR_WARNING "PARAM is 'set' ...")
add_definitions("-DPARAM=1")
else()
message(AUTHOR_WARNING "PARAM is not 'set' ...")
add_definitions("--bogus-option")
endif()
endif()

The CMake process is initiated with the following command line.

$ cmake -DPARAM=set ..

And, usage of the override file is set with the following before the
project is defined.

set(CMAKE_USER_MAKE_RULES_OVERRIDE
${CMAKE_CURRENT_SOURCE_DIR}/override_compiler_flags.cmake)

I have attached the output of the CMake run as well.

Is this a bug in that subsequent processing of the override file is not
using the cached value of PARAM?
Or, is there something wrong with the override file itself?

Thanks!

Mike


  
  
  


  

-- 

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

2017-02-15 Thread Bill Newcomb

My top-level CMakeLists.txt files always end up with a lot of

if(NOT_DEFINED foo)
 set(foo bar)
endif()

things to allow people to pass interesting things on the command line or 
to write their own "set this and that" CMakeLists.txt and include the 
top-level one.

It would improve readability to have set_if_not_set and friends from 
CTest.cmake available in a separate module or, better still, as language 
primitives, either as-is or like

set(IF_NOT_SET foo bar)

or maybe

set(foo bar IF_NOT_SET)

Obviously I could define set_if_not_set at the top of each top-level 
CMakeLists.txt, but the above would be nicer.

What do you think?

Thanks,
B.

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
-- 

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] Intel C Generator for Cmake?

2017-02-15 Thread J Decker

Toolchain is probably what you want

http://stackoverflow.com/questions/9129233/recommended-ways-to-use-cmake-with-icc-via-configuration-options

https://cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F

"cmake intel toochain" search.

On Wed, Feb 15, 2017 at 6:42 AM, Thompson, KT  wrote:

> Tony,
>
>
>
> I don’t have access to the Intel compiler on Windows to try this out.
> However, in an old post I found, it was suggested that you can use cmake’s
> “-T” option to select the Intel compiler when the generator is “Visual
> Studio”.
>
>
>
> For example:  -T"Intel C++ Compiler XE 13.0"
>
>
>
> Ref: https://software.intel.com/en-us/forums/intel-c-compiler/topic/456288
>
>
>
> -kt
>
>
>
>
>
> *From:* CMake [mailto:cmake-boun...@cmake.org] *On Behalf Of *Tony Garratt
> *Sent:* Wednesday, February 15, 2017 6:21 AM
> *To:* Petr Kmoch 
> *Cc:* cmake@cmake.org
> *Subject:* Re: [CMake] Intel C Generator for Cmake?
>
>
>
>
>
> Re: my previous email. To use the Intel C compilers I just can modify the
> VS settings. So I have a way forward.
>
>
>
> Regards,
>
> Tony
>
>
>
> On Wed, Feb 15, 2017 at 12:25 PM, Petr Kmoch  wrote:
>
> Hi Tony,
>
> generators are for different *buildsystems*: a generator for Makefiles, a
> generator for Visual Studio solutions, a generator for Ninja files, a
> generator for Eclipse projects etc.
>
> Intel C and Intel Fortran are compilers, not buildsystems. You should be
> able to use them with any generator whose buildsystem supports those
> compilers.
>
> On Windows, CMake supports generation of vfproj files using the Visual
> Studio generator. I don't know if Intel C has its own Visual Studio project
> type in the same fashion, and if so, whether CMake supports it.
>
> One of the setups I maintain uses Visual Studio's C++ compiler and Intel
> Fortran compiler on Windows using the Visual Studio generator, and
> conceptually, it's as simple as this:
>
> call ...\ifortvars.bat ...
>
> set FC=ifort
>
> cmake ...
>
> Petr
>
>
>
> On 15 February 2017 at 12:34, Tony Garratt  wrote:
>
> I am having to switch to cmake from autotools for a third party tool I
> want to build. We use Intel C and Intel Fortran on Windows. I see no
> mention of an Intel C generator for cmake. I presume this means there is
> not one? If so, can I create my own Intel C generator please?
>
>
>
> Rgeards,
>
> Tony
>
>
>
> --
>
> *Dr Tony Garratt*
>
>
>
>
>
>
>
>
>
> --
>
> *Dr Tony Garratt*
>
> Tel: +44 7624 309933 <+44%2076%202430%209933>
>
> --
>
> 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-developers] Debugger for CMake

2017-02-15 Thread Brad King

On 02/13/2017 10:18 PM, Justin Berger wrote:
> Should I resumbit the MR to continue the discussion there?

Justin submitted a new MR [1].  I encourage everyone that participated
in this thread to take a look.

Thanks,
-Brad


[1] https://gitlab.kitware.com/cmake/cmake/merge_requests/483

-- 

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-commits] CMake branch, next, updated. v3.8.0-rc1-182-gb0ea076

2017-02-15 Thread 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  b0ea076370600cd3e6a5d04a90667c0d2a8e4727 (commit)
   via  55fb46d273e8ab51d5df366286052c71b9008437 (commit)
   via  d7c80f60362cbc40216fab67318d94988030315c (commit)
  from  d4c222c5af0612ae0ec200bc540a733d0941fa19 (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=b0ea076370600cd3e6a5d04a90667c0d2a8e4727
commit b0ea076370600cd3e6a5d04a90667c0d2a8e4727
Merge: d4c222c 55fb46d
Author: Brad King 
AuthorDate: Wed Feb 15 11:12:26 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 15 11:12:26 2017 -0500

Merge topic 'cuda-msvc-flags' into next

55fb46d2 CUDA: Fix default compiler flags on Windows
d7c80f60 CUDA: Fix test cases to not override CUDA flags


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=55fb46d273e8ab51d5df366286052c71b9008437
commit 55fb46d273e8ab51d5df366286052c71b9008437
Author: Brad King 
AuthorDate: Tue Feb 14 15:11:25 2017 -0500
Commit: Brad King 
CommitDate: Wed Feb 15 11:12:12 2017 -0500

CUDA: Fix default compiler flags on Windows

Fix the default values of `CMAKE_CUDA_FLAGS[_]` on Windows to
make the host compiler flags match those produced for C++ by the
`Platform/Windows-MSVC` module.  This makes the flags consistent with
those used for C++.

diff --git a/Modules/Compiler/NVIDIA-CUDA.cmake 
b/Modules/Compiler/NVIDIA-CUDA.cmake
index 7903313..316cab8 100644
--- a/Modules/Compiler/NVIDIA-CUDA.cmake
+++ b/Modules/Compiler/NVIDIA-CUDA.cmake
@@ -7,16 +7,15 @@ if(NOT "x${CMAKE_CUDA_SIMULATE_ID}" STREQUAL "xMSVC")
   # CMAKE_SHARED_LIBRARY_CUDA_FLAGS is sent to the host linker so we
   # don't need to forward it through nvcc.
   set(CMAKE_SHARED_LIBRARY_CUDA_FLAGS -fPIC)
+  string(APPEND CMAKE_CUDA_FLAGS_INIT " ")
+  string(APPEND CMAKE_CUDA_FLAGS_DEBUG_INIT " -g")
+  string(APPEND CMAKE_CUDA_FLAGS_RELEASE_INIT " -O3 -DNDEBUG")
+  string(APPEND CMAKE_CUDA_FLAGS_MINSIZEREL_INIT " -O1 -DNDEBUG")
+  string(APPEND CMAKE_CUDA_FLAGS_RELWITHDEBINFO_INIT " -O2 -g -DNDEBUG")
 endif()
 set(CMAKE_SHARED_LIBRARY_CREATE_CUDA_FLAGS -shared)
 set(CMAKE_INCLUDE_SYSTEM_FLAG_CUDA -isystem=)
 
-string(APPEND CMAKE_CUDA_FLAGS_INIT " ")
-string(APPEND CMAKE_CUDA_FLAGS_DEBUG_INIT " -g")
-string(APPEND CMAKE_CUDA_FLAGS_MINSIZEREL_INIT " -O1 -DNDEBUG")
-string(APPEND CMAKE_CUDA_FLAGS_RELEASE_INIT " -O3 -DNDEBUG")
-string(APPEND CMAKE_CUDA_FLAGS_RELWITHDEBINFO_INIT " -O2 -g -DNDEBUG")
-
 if("x${CMAKE_CUDA_SIMULATE_ID}" STREQUAL "xMSVC")
   set(CMAKE_CUDA_STANDARD_DEFAULT "")
 else()
diff --git a/Modules/Platform/Windows-NVIDIA-CUDA.cmake 
b/Modules/Platform/Windows-NVIDIA-CUDA.cmake
index eda41e0..845fa4b 100644
--- a/Modules/Platform/Windows-NVIDIA-CUDA.cmake
+++ b/Modules/Platform/Windows-NVIDIA-CUDA.cmake
@@ -35,10 +35,12 @@ set(CMAKE_CUDA_DEVICE_LINK_LIBRARY
 set(CMAKE_CUDA_DEVICE_LINK_EXECUTABLE
   "   -shared -dlink 
 -o   -Xcompiler=-Fd,-FS")
 
-string(APPEND CMAKE_CUDA_FLAGS_INIT " -Xcompiler=-GR,-EHsc")
-string(APPEND CMAKE_CUDA_FLAGS_DEBUG_INIT " -Xcompiler=-MDd,-Zi,-RTC1")
-string(APPEND CMAKE_CUDA_FLAGS_RELEASE_INIT " -Xcompiler=-MD")
-string(APPEND CMAKE_CUDA_FLAGS_RELWITHDEBINFO_INIT " -Xcompiler=-MD")
-string(APPEND CMAKE_CUDA_FLAGS_MINSIZEREL_INIT " -Xcompiler=-MD")
+string(REPLACE "/D" "-D" _PLATFORM_DEFINES_CUDA 
"${_PLATFORM_DEFINES}${_PLATFORM_DEFINES_CXX}")
+
+string(APPEND CMAKE_CUDA_FLAGS_INIT " ${PLATFORM_DEFINES_CUDA} -D_WINDOWS 
-Xcompiler=\"/W3${_FLAGS_CXX}\"")
+string(APPEND CMAKE_CUDA_FLAGS_DEBUG_INIT " -Xcompiler=\"-MDd -Zi -Ob0 -Od 
${_RTC1}\"")
+string(APPEND CMAKE_CUDA_FLAGS_RELEASE_INIT " -Xcompiler=\"-MD -O2 -Ob2\" 
-DNDEBUG")
+string(APPEND CMAKE_CUDA_FLAGS_RELWITHDEBINFO_INIT " -Xcompiler=\"-MD -Zi -O2 
-Ob1\" -DNDEBUG")
+string(APPEND CMAKE_CUDA_FLAGS_MINSIZEREL_INIT " -Xcompiler=\"-MD -O1 -Ob1\" 
-DNDEBUG")
 
 set(CMAKE_CUDA_STANDARD_LIBRARIES_INIT "${CMAKE_C_STANDARD_LIBRARIES_INIT}")

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d7c80f60362cbc40216fab67318d94988030315c
commit d7c80f60362cbc40216fab67318d94988030315c
Author: Brad King 
AuthorDate: Tue Feb 14 15:09:55 2017 -0500
Commit: Brad King 
CommitDate: Wed Feb 15 11:12:09 2017 -0500

CUDA: Fix test cases to not override CUDA flags

Append to `CMAKE_CUDA_FLAGS` instead of overwriting it.

diff --git a/Tests/Cuda/Complex/CMakeLists.txt 
b/Tests/Cuda/Complex/CMakeLists.txt
index 9a3703a..bff7d07 100644
--- a/Tests/Cuda/Complex/CMakeLists.txt

[Cmake-commits] CMake branch, next, updated. v3.8.0-rc1-179-gd4c222c

2017-02-15 Thread 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  d4c222c5af0612ae0ec200bc540a733d0941fa19 (commit)
   via  84c3eddac6e9de29995141f2cd12bb5cba16cbb5 (commit)
  from  a146979be3b0890d376f6c722f3b0744189367c9 (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=d4c222c5af0612ae0ec200bc540a733d0941fa19
commit d4c222c5af0612ae0ec200bc540a733d0941fa19
Merge: a146979 84c3edd
Author: Brad King 
AuthorDate: Wed Feb 15 11:12:00 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 15 11:12:00 2017 -0500

Merge topic 'cuda-msvc-flags' into next

84c3edda fixup! CUDA: Fix default compiler flags on Windows


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=84c3eddac6e9de29995141f2cd12bb5cba16cbb5
commit 84c3eddac6e9de29995141f2cd12bb5cba16cbb5
Author: Brad King 
AuthorDate: Wed Feb 15 11:10:22 2017 -0500
Commit: Brad King 
CommitDate: Wed Feb 15 11:10:22 2017 -0500

fixup! CUDA: Fix default compiler flags on Windows

diff --git a/Modules/Platform/Windows-NVIDIA-CUDA.cmake 
b/Modules/Platform/Windows-NVIDIA-CUDA.cmake
index 23473ed..845fa4b 100644
--- a/Modules/Platform/Windows-NVIDIA-CUDA.cmake
+++ b/Modules/Platform/Windows-NVIDIA-CUDA.cmake
@@ -38,7 +38,7 @@ set(CMAKE_CUDA_DEVICE_LINK_EXECUTABLE
 string(REPLACE "/D" "-D" _PLATFORM_DEFINES_CUDA 
"${_PLATFORM_DEFINES}${_PLATFORM_DEFINES_CXX}")
 
 string(APPEND CMAKE_CUDA_FLAGS_INIT " ${PLATFORM_DEFINES_CUDA} -D_WINDOWS 
-Xcompiler=\"/W3${_FLAGS_CXX}\"")
-string(APPEND CMAKE_CUDA_FLAGS_DEBUG_INIT " -Xcompiler=\"-MDd -Zi ${_RTC1}\"")
+string(APPEND CMAKE_CUDA_FLAGS_DEBUG_INIT " -Xcompiler=\"-MDd -Zi -Ob0 -Od 
${_RTC1}\"")
 string(APPEND CMAKE_CUDA_FLAGS_RELEASE_INIT " -Xcompiler=\"-MD -O2 -Ob2\" 
-DNDEBUG")
 string(APPEND CMAKE_CUDA_FLAGS_RELWITHDEBINFO_INIT " -Xcompiler=\"-MD -Zi -O2 
-Ob1\" -DNDEBUG")
 string(APPEND CMAKE_CUDA_FLAGS_MINSIZEREL_INIT " -Xcompiler=\"-MD -O1 -Ob1\" 
-DNDEBUG")

---

Summary of changes:
 Modules/Platform/Windows-NVIDIA-CUDA.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

Re: [CMake] import external library

2017-02-15 Thread Florent Castelli


You can either unpack the target at generation time (recommended).
Or you could create an INTERFACE target instead.

The first solution is recommended as I believe it's important to have 
access to all the sources (for IDEs for example) before actually 
starting the build process.


/Florent

On 15/02/2017 14:12, Wagner Martin wrote:


Hi @all,

I’ve tried importing an external library like that: 
stackoverflow.com/questions/31274577


I have the same use case, except that my custom target does not call 
make but does unpack a tar archive containing headers and .a.


My problem is that the step

“

# specify where the library is and where to find the headers

set_target_properties(lib2

PROPERTIES

IMPORTED_LOCATION ${LIB_FILE}

INTERFACE_INCLUDE_DIRECTORIES ${LIB_HEADER_FOLDER})

“

fails. When running cmake, I get an error that the header dir 
specified with “INTERFACE_INCLUDE_DIRECTORIES” does not exist.


“

CMake Error in src/CMakeLists.txt:

  Imported target "whatever" includes non-existent path

"/path/to/include"

  in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:

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

  * An install or uninstall procedure did not complete successfully.

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

  provide.

“

This is true, as the header path is only generated when running the 
unpack target. Is there a way to tell cmake to skip this check?


Thanks!

Regards,

Martin





-- 

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] Intel C Generator for Cmake?

2017-02-15 Thread Thompson, KT

Tony,

I don’t have access to the Intel compiler on Windows to try this out. However, 
in an old post I found, it was suggested that you can use cmake’s “-T” option 
to select the Intel compiler when the generator is “Visual Studio”.

For example:  -T"Intel C++ Compiler XE 13.0"

Ref: https://software.intel.com/en-us/forums/intel-c-compiler/topic/456288

-kt


From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Tony Garratt
Sent: Wednesday, February 15, 2017 6:21 AM
To: Petr Kmoch 
Cc: cmake@cmake.org
Subject: Re: [CMake] Intel C Generator for Cmake?


Re: my previous email. To use the Intel C compilers I just can modify the VS 
settings. So I have a way forward.

Regards,
Tony

On Wed, Feb 15, 2017 at 12:25 PM, Petr Kmoch 
> wrote:
Hi Tony,
generators are for different *buildsystems*: a generator for Makefiles, a 
generator for Visual Studio solutions, a generator for Ninja files, a generator 
for Eclipse projects etc.
Intel C and Intel Fortran are compilers, not buildsystems. You should be able 
to use them with any generator whose buildsystem supports those compilers.
On Windows, CMake supports generation of vfproj files using the Visual Studio 
generator. I don't know if Intel C has its own Visual Studio project type in 
the same fashion, and if so, whether CMake supports it.
One of the setups I maintain uses Visual Studio's C++ compiler and Intel 
Fortran compiler on Windows using the Visual Studio generator, and 
conceptually, it's as simple as this:
call ...\ifortvars.bat ...
set FC=ifort
cmake ...
Petr

On 15 February 2017 at 12:34, Tony Garratt 
> wrote:
I am having to switch to cmake from autotools for a third party tool I want to 
build. We use Intel C and Intel Fortran on Windows. I see no mention of an 
Intel C generator for cmake. I presume this means there is not one? If so, can 
I create my own Intel C generator please?

Rgeards,
Tony

--
Dr Tony Garratt





--
Dr Tony Garratt
Tel: +44 7624 309933
-- 

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] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...

2017-02-15 Thread Nils Gladitz


On 15.02.2017 15:16, Malfettone, Kris wrote:


Just noticed a problem in my example.  In my attempt to simplify my 
example I moved both outputs into the same folder which in my opinion 
is invalid because both output file names are the same.  However, the 
same basic setup does reproduce the problem if you move the two 
targets into their own subdirs. I was just trying to avoid describing 
that in the email. Here is what I mean below:




I thought you meant you had a target named "test" but apparently only 
your output is named that way.

That certainly isn't covered by the existing policy.

Nils
-- 

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.8.0-rc1-177-ga146979

2017-02-15 Thread 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  a146979be3b0890d376f6c722f3b0744189367c9 (commit)
   via  20ae76b1da82d87792fb54335dbf95e871261f52 (commit)
  from  13314a3e27942a44e747a9ba52e0c819a1b602d2 (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=a146979be3b0890d376f6c722f3b0744189367c9
commit a146979be3b0890d376f6c722f3b0744189367c9
Merge: 13314a3 20ae76b
Author: Brad King 
AuthorDate: Wed Feb 15 09:26:23 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 15 09:26:23 2017 -0500

Merge topic 'command-cleanup-fix' into next

20ae76b1 cmDisallowedCommand: Forward final pass too


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=20ae76b1da82d87792fb54335dbf95e871261f52
commit 20ae76b1da82d87792fb54335dbf95e871261f52
Author: Brad King 
AuthorDate: Wed Feb 15 09:18:26 2017 -0500
Commit: Brad King 
CommitDate: Wed Feb 15 09:22:22 2017 -0500

cmDisallowedCommand: Forward final pass too

Refactoring in commit 7fb14775 (cmDisallowedCommand: extract policy
checking from cmCommand, 2016-12-26) introduced a wrapper for
disallowed commands that forwards to their original commands.
This broke the `export_library_dependencies` command that uses
a final pass.  Forward the final pass too to fix it.

diff --git a/Source/cmDisallowedCommand.h b/Source/cmDisallowedCommand.h
index 9cf5e6f..00b0183 100644
--- a/Source/cmDisallowedCommand.h
+++ b/Source/cmDisallowedCommand.h
@@ -34,6 +34,13 @@ public:
   bool InitialPass(std::vector const& args,
cmExecutionStatus& status) CM_OVERRIDE;
 
+  void FinalPass() CM_OVERRIDE { this->Command->FinalPass(); }
+
+  bool HasFinalPass() const CM_OVERRIDE
+  {
+return this->Command->HasFinalPass();
+  }
+
   bool IsScriptable() const CM_OVERRIDE
   {
 return this->Command->IsScriptable();

---

Summary of changes:
 Source/cmDisallowedCommand.h |7 +++
 1 file changed, 7 insertions(+)


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

Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...

2017-02-15 Thread Malfettone, Kris

Just noticed a problem in my example.  In my attempt to simplify my example I 
moved both outputs into the same folder which in my opinion is invalid because 
both output file names are the same.  However, the same basic setup does 
reproduce the problem if you move the two targets into their own subdirs.  I 
was just trying to avoid describing that in the email.  Here is what I mean 
below:

Top level CMakeLists.txt:
cmake_minimum_required(VERSION 3.7)
enable_testing()
project("bugreproduce")
add_subdirectory("subdir")
add_subdirectory("subdir2")
subdir with CMakeLists.txt:
add_executable( "Foo.test" foo_test.cpp )
set_target_properties("Foo.test" PROPERTIES OUTPUT_NAME test )
add_test(NAME "Foo.test" COMMAND test)
subdir2 with CMakeLists.txt:
add_executable( "Bar.test" bar_test.cpp )
set_target_properties("Bar.test" PROPERTIES OUTPUT_NAME test )
add_test(NAME "Bar.test" COMMAND test )

Contents of both source files (obviously in their respective subdirectories):
int main( int, char** )
{
   return 0;
}

Sorry for that.

From: Malfettone, Kris
Sent: Wednesday, February 15, 2017 9:07 AM
To: Malfettone, Kris ; Nils Gladitz 
; cmake@cmake.org
Subject: RE: [CMake] Potential bug: Having executables named "test" causes 
Ninja generator to generate ambiguous rules...

So I was able to reproduce the problem with this very simple CMakeLists.txt 
setup.  I cannot attach source files due to my company's mail server 
automatically stripping them out attachments with code but here is all you 
would need to reproduce the problem:

Single CMakeLists.txt with the following:
cmake_minimum_required(VERSION 3.7)
enable_testing()
project("bugreproduce")
add_executable( "Foo.test" foo_test.cpp )
add_executable( "Bar.test" bar_test.cpp )
set_target_properties("Foo.test" PROPERTIES OUTPUT_NAME test )
set_target_properties("Bar.test" PROPERTIES OUTPUT_NAME test )
add_test(NAME "Foo.test" COMMAND test)
add_test(NAME "Bar.test" COMMAND test )
Two source files named foo_test.cpp and bar_test.cpp both containing the 
following code in the same directory:
int main( int, char** )
{
   return 0;
}

If you generate a Makefile based solution everything works fine.  However, if 
you generate a ninja based solution then you get the following:
ninja: warning: multiple rules generate test. builds involving this target will 
not be correct; continuing anyway [-w dupbuild=warn]
ninja: warning: multiple rules generate test. builds involving this target will 
not be correct; continuing anyway [-w dupbuild=warn]

-Kris

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Malfettone, Kris
Sent: Wednesday, February 15, 2017 8:27 AM
To: Nils Gladitz >; 
cmake@cmake.org
Subject: Re: [CMake] Potential bug: Having executables named "test" causes 
Ninja generator to generate ambiguous rules...

Good to know.  Thanks for the quick response.  Though I do not believe I am 
violating that particular rule here.  That is why I do not receive either a 
warning or error from CMake in my output.

The only warning I see is from ninja:
ninja: warning: multiple rules generate MD/MDF/Formats/SIG/BCP/v0_1/test. 
builds involving this target will not be correct; continuing anyway [-w 
dupbuild=warn]
ninja: warning: multiple rules generate MD/MDF/Formats/SIG/BCP/v0_2/test. 
builds involving this target will not be correct; continuing anyway [-w 
dupbuild=warn]
ninja: warning: multiple rules generate test. builds involving this target will 
not be correct; continuing anyway [-w dupbuild=warn]

I think the difference is that my target names are:
MD.MDF.Formats.SIG.BCP.v0_1.test
MD.MDF.Formats.SIG.BCP.v0_2.test

It is the ninja generator that is trying to setup aliases for each of them as a 
shortened form.  So I think one of the following statements are true:

* The cmake rule intended for the above two target names to be invalid. 
 But the check to issue a warning or error has a bug causing them to be missed. 
 This would explain why I do not get the error in my configure results.

* The cmake rule intended for the above two target names to be valid.  
However, on further reflection the rule should be made stricter to include my 
target names above.  This would then require and update to the cmake code 
checking that policy and lead to me actually getting a warning or error from 
cmake during configure.

* The ninja generator has a bug and is setting up ambiguous aliases for 
what CMake considers valid target names.

My project is huge so I will try and craft a simplified CMakeLists.txt example 
to reproduce the problem as well.

Does this make sense?  Am I still missing something?

-Kris

From: Nils Gladitz [mailto:nilsglad...@gmail.com]
Sent: Wednesday, February 15, 2017 3:36 AM
To: Malfettone, Kris 
>;

Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...

2017-02-15 Thread Malfettone, Kris

So I was able to reproduce the problem with this very simple CMakeLists.txt 
setup.  I cannot attach source files due to my company's mail server 
automatically stripping them out attachments with code but here is all you 
would need to reproduce the problem:

Single CMakeLists.txt with the following:
cmake_minimum_required(VERSION 3.7)
enable_testing()
project("bugreproduce")
add_executable( "Foo.test" foo_test.cpp )
add_executable( "Bar.test" bar_test.cpp )
set_target_properties("Foo.test" PROPERTIES OUTPUT_NAME test )
set_target_properties("Bar.test" PROPERTIES OUTPUT_NAME test )
add_test(NAME "Foo.test" COMMAND test)
add_test(NAME "Bar.test" COMMAND test )
Two source files named foo_test.cpp and bar_test.cpp both containing the 
following code in the same directory:
int main( int, char** )
{
   return 0;
}

If you generate a Makefile based solution everything works fine.  However, if 
you generate a ninja based solution then you get the following:
ninja: warning: multiple rules generate test. builds involving this target will 
not be correct; continuing anyway [-w dupbuild=warn]
ninja: warning: multiple rules generate test. builds involving this target will 
not be correct; continuing anyway [-w dupbuild=warn]

-Kris

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Malfettone, Kris
Sent: Wednesday, February 15, 2017 8:27 AM
To: Nils Gladitz ; cmake@cmake.org
Subject: Re: [CMake] Potential bug: Having executables named "test" causes 
Ninja generator to generate ambiguous rules...

Good to know.  Thanks for the quick response.  Though I do not believe I am 
violating that particular rule here.  That is why I do not receive either a 
warning or error from CMake in my output.

The only warning I see is from ninja:
ninja: warning: multiple rules generate MD/MDF/Formats/SIG/BCP/v0_1/test. 
builds involving this target will not be correct; continuing anyway [-w 
dupbuild=warn]
ninja: warning: multiple rules generate MD/MDF/Formats/SIG/BCP/v0_2/test. 
builds involving this target will not be correct; continuing anyway [-w 
dupbuild=warn]
ninja: warning: multiple rules generate test. builds involving this target will 
not be correct; continuing anyway [-w dupbuild=warn]

I think the difference is that my target names are:
MD.MDF.Formats.SIG.BCP.v0_1.test
MD.MDF.Formats.SIG.BCP.v0_2.test

It is the ninja generator that is trying to setup aliases for each of them as a 
shortened form.  So I think one of the following statements are true:

* The cmake rule intended for the above two target names to be invalid. 
 But the check to issue a warning or error has a bug causing them to be missed. 
 This would explain why I do not get the error in my configure results.

* The cmake rule intended for the above two target names to be valid.  
However, on further reflection the rule should be made stricter to include my 
target names above.  This would then require and update to the cmake code 
checking that policy and lead to me actually getting a warning or error from 
cmake during configure.

* The ninja generator has a bug and is setting up ambiguous aliases for 
what CMake considers valid target names.

My project is huge so I will try and craft a simplified CMakeLists.txt example 
to reproduce the problem as well.

Does this make sense?  Am I still missing something?

-Kris

From: Nils Gladitz [mailto:nilsglad...@gmail.com]
Sent: Wednesday, February 15, 2017 3:36 AM
To: Malfettone, Kris 
>; 
cmake@cmake.org
Subject: Re: [CMake] Potential bug: Having executables named "test" causes 
Ninja generator to generate ambiguous rules...

On 14.02.2017 22:53, Malfettone, Kris wrote:
If so, are executables named "test" no longer supported?
Am I missing something or wrong in some way?


Issues existed before 3.0 but since 3.0 "test" and similarly problematic target 
names have been explicitly reserved.

Any CMake Version >= 3.0 will issue a warning (when the required version is < 
3.0) or an error (when the required version is >= 3.0) by default:
https://cmake.org/cmake/help/v3.8/policy/CMP0037.html

Nils



IMPORTANT: The information contained in this email and/or its attachments is 
confidential. If you are not the intended recipient, please notify the sender 
immediately by reply and immediately delete this message and all its 
attachments. Any review, use, reproduction, disclosure or dissemination of this 
message or any attachment by an unintended recipient is strictly prohibited. 
Neither this message nor any attachment is intended as or should be construed 
as an offer, solicitation or recommendation to buy or sell any security or 
other financial instrument. Neither the sender, his or her employer nor any of 
their respective affiliates makes any warranties as to the completeness or 
accuracy of any of the information contained

[Cmake-commits] CMake branch, next, updated. v3.8.0-rc1-175-g13314a3

2017-02-15 Thread 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  13314a3e27942a44e747a9ba52e0c819a1b602d2 (commit)
   via  67fbc2b24e549ce159378277d651e72302b9fc70 (commit)
   via  6581d3c2df248a6afdcbf19c48bf6d69c29d5bd0 (commit)
  from  4e93e9036ad904278b1634e082dbc627aea868e8 (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=13314a3e27942a44e747a9ba52e0c819a1b602d2
commit 13314a3e27942a44e747a9ba52e0c819a1b602d2
Merge: 4e93e90 67fbc2b
Author: Brad King 
AuthorDate: Wed Feb 15 08:41:59 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 15 08:41:59 2017 -0500

Merge topic 'cuda-msvc-flags' into next

67fbc2b2 CUDA: Fix default compiler flags on Windows
6581d3c2 CUDA: Fix test cases to not override CUDA flags


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=67fbc2b24e549ce159378277d651e72302b9fc70
commit 67fbc2b24e549ce159378277d651e72302b9fc70
Author: Brad King 
AuthorDate: Tue Feb 14 15:11:25 2017 -0500
Commit: Brad King 
CommitDate: Wed Feb 15 08:29:54 2017 -0500

CUDA: Fix default compiler flags on Windows

Fix the default values of `CMAKE_CUDA_FLAGS[_]` on Windows to
make the host compiler flags match those produced for C++ by the
`Platform/Windows-MSVC` module.  This makes the flags consistent with
those used for C++.

diff --git a/Modules/Compiler/NVIDIA-CUDA.cmake 
b/Modules/Compiler/NVIDIA-CUDA.cmake
index 7903313..316cab8 100644
--- a/Modules/Compiler/NVIDIA-CUDA.cmake
+++ b/Modules/Compiler/NVIDIA-CUDA.cmake
@@ -7,16 +7,15 @@ if(NOT "x${CMAKE_CUDA_SIMULATE_ID}" STREQUAL "xMSVC")
   # CMAKE_SHARED_LIBRARY_CUDA_FLAGS is sent to the host linker so we
   # don't need to forward it through nvcc.
   set(CMAKE_SHARED_LIBRARY_CUDA_FLAGS -fPIC)
+  string(APPEND CMAKE_CUDA_FLAGS_INIT " ")
+  string(APPEND CMAKE_CUDA_FLAGS_DEBUG_INIT " -g")
+  string(APPEND CMAKE_CUDA_FLAGS_RELEASE_INIT " -O3 -DNDEBUG")
+  string(APPEND CMAKE_CUDA_FLAGS_MINSIZEREL_INIT " -O1 -DNDEBUG")
+  string(APPEND CMAKE_CUDA_FLAGS_RELWITHDEBINFO_INIT " -O2 -g -DNDEBUG")
 endif()
 set(CMAKE_SHARED_LIBRARY_CREATE_CUDA_FLAGS -shared)
 set(CMAKE_INCLUDE_SYSTEM_FLAG_CUDA -isystem=)
 
-string(APPEND CMAKE_CUDA_FLAGS_INIT " ")
-string(APPEND CMAKE_CUDA_FLAGS_DEBUG_INIT " -g")
-string(APPEND CMAKE_CUDA_FLAGS_MINSIZEREL_INIT " -O1 -DNDEBUG")
-string(APPEND CMAKE_CUDA_FLAGS_RELEASE_INIT " -O3 -DNDEBUG")
-string(APPEND CMAKE_CUDA_FLAGS_RELWITHDEBINFO_INIT " -O2 -g -DNDEBUG")
-
 if("x${CMAKE_CUDA_SIMULATE_ID}" STREQUAL "xMSVC")
   set(CMAKE_CUDA_STANDARD_DEFAULT "")
 else()
diff --git a/Modules/Platform/Windows-NVIDIA-CUDA.cmake 
b/Modules/Platform/Windows-NVIDIA-CUDA.cmake
index eda41e0..23473ed 100644
--- a/Modules/Platform/Windows-NVIDIA-CUDA.cmake
+++ b/Modules/Platform/Windows-NVIDIA-CUDA.cmake
@@ -35,10 +35,12 @@ set(CMAKE_CUDA_DEVICE_LINK_LIBRARY
 set(CMAKE_CUDA_DEVICE_LINK_EXECUTABLE
   "   -shared -dlink 
 -o   -Xcompiler=-Fd,-FS")
 
-string(APPEND CMAKE_CUDA_FLAGS_INIT " -Xcompiler=-GR,-EHsc")
-string(APPEND CMAKE_CUDA_FLAGS_DEBUG_INIT " -Xcompiler=-MDd,-Zi,-RTC1")
-string(APPEND CMAKE_CUDA_FLAGS_RELEASE_INIT " -Xcompiler=-MD")
-string(APPEND CMAKE_CUDA_FLAGS_RELWITHDEBINFO_INIT " -Xcompiler=-MD")
-string(APPEND CMAKE_CUDA_FLAGS_MINSIZEREL_INIT " -Xcompiler=-MD")
+string(REPLACE "/D" "-D" _PLATFORM_DEFINES_CUDA 
"${_PLATFORM_DEFINES}${_PLATFORM_DEFINES_CXX}")
+
+string(APPEND CMAKE_CUDA_FLAGS_INIT " ${PLATFORM_DEFINES_CUDA} -D_WINDOWS 
-Xcompiler=\"/W3${_FLAGS_CXX}\"")
+string(APPEND CMAKE_CUDA_FLAGS_DEBUG_INIT " -Xcompiler=\"-MDd -Zi ${_RTC1}\"")
+string(APPEND CMAKE_CUDA_FLAGS_RELEASE_INIT " -Xcompiler=\"-MD -O2 -Ob2\" 
-DNDEBUG")
+string(APPEND CMAKE_CUDA_FLAGS_RELWITHDEBINFO_INIT " -Xcompiler=\"-MD -Zi -O2 
-Ob1\" -DNDEBUG")
+string(APPEND CMAKE_CUDA_FLAGS_MINSIZEREL_INIT " -Xcompiler=\"-MD -O1 -Ob1\" 
-DNDEBUG")
 
 set(CMAKE_CUDA_STANDARD_LIBRARIES_INIT "${CMAKE_C_STANDARD_LIBRARIES_INIT}")

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6581d3c2df248a6afdcbf19c48bf6d69c29d5bd0
commit 6581d3c2df248a6afdcbf19c48bf6d69c29d5bd0
Author: Brad King 
AuthorDate: Tue Feb 14 15:09:55 2017 -0500
Commit: Brad King 
CommitDate: Wed Feb 15 08:29:54 2017 -0500

CUDA: Fix test cases to not override CUDA flags

Append to `CMAKE_CUDA_FLAGS` instead of overwriting it.

diff --git a/Tests/Cuda/Complex/CMakeLists.txt 
b/Tests/Cuda/Complex/CMakeLists.txt
index 9a3703a..bff7d07 100644
--- a/Tests/Cuda/Complex/CMakeLists.txt
+++

Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...

2017-02-15 Thread Malfettone, Kris

Good to know.  Thanks for the quick response.  Though I do not believe I am 
violating that particular rule here.  That is why I do not receive either a 
warning or error from CMake in my output.

The only warning I see is from ninja:
ninja: warning: multiple rules generate MD/MDF/Formats/SIG/BCP/v0_1/test. 
builds involving this target will not be correct; continuing anyway [-w 
dupbuild=warn]
ninja: warning: multiple rules generate MD/MDF/Formats/SIG/BCP/v0_2/test. 
builds involving this target will not be correct; continuing anyway [-w 
dupbuild=warn]
ninja: warning: multiple rules generate test. builds involving this target will 
not be correct; continuing anyway [-w dupbuild=warn]

I think the difference is that my target names are:
MD.MDF.Formats.SIG.BCP.v0_1.test
MD.MDF.Formats.SIG.BCP.v0_2.test

It is the ninja generator that is trying to setup aliases for each of them as a 
shortened form.  So I think one of the following statements are true:

* The cmake rule intended for the above two target names to be invalid. 
 But the check to issue a warning or error has a bug causing them to be missed. 
 This would explain why I do not get the error in my configure results.

* The cmake rule intended for the above two target names to be valid.  
However, on further reflection the rule should be made stricter to include my 
target names above.  This would then require and update to the cmake code 
checking that policy and lead to me actually getting a warning or error from 
cmake during configure.

* The ninja generator has a bug and is setting up ambiguous aliases for 
what CMake considers valid target names.

My project is huge so I will try and craft a simplified CMakeLists.txt example 
to reproduce the problem as well.

Does this make sense?  Am I still missing something?

-Kris


From: Nils Gladitz [mailto:nilsglad...@gmail.com]
Sent: Wednesday, February 15, 2017 3:36 AM
To: Malfettone, Kris ; cmake@cmake.org
Subject: Re: [CMake] Potential bug: Having executables named "test" causes 
Ninja generator to generate ambiguous rules...

On 14.02.2017 22:53, Malfettone, Kris wrote:
If so, are executables named "test" no longer supported?
Am I missing something or wrong in some way?


Issues existed before 3.0 but since 3.0 "test" and similarly problematic target 
names have been explicitly reserved.

Any CMake Version >= 3.0 will issue a warning (when the required version is < 
3.0) or an error (when the required version is >= 3.0) by default:
https://cmake.org/cmake/help/v3.8/policy/CMP0037.html

Nils



IMPORTANT: The information contained in this email and/or its attachments is 
confidential. If you are not the intended recipient, please notify the sender 
immediately by reply and immediately delete this message and all its 
attachments. Any review, use, reproduction, disclosure or dissemination of this 
message or any attachment by an unintended recipient is strictly prohibited. 
Neither this message nor any attachment is intended as or should be construed 
as an offer, solicitation or recommendation to buy or sell any security or 
other financial instrument. Neither the sender, his or her employer nor any of 
their respective affiliates makes any warranties as to the completeness or 
accuracy of any of the information contained herein or that this message or any 
of its attachments is free of viruses.
-- 

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, release, updated. v3.8.0-rc1-18-g272c348

2017-02-15 Thread 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  272c348d5a1c3f713586e05e0d73fd18441f7bb2 (commit)
   via  59ed323d4648a61d911679190273c35f950e20ce (commit)
   via  81ebf4be3eeabe7f1fc42929b3cc46e515fd4800 (commit)
   via  1c60231ca546597ef8b80e7340c8991b06387cbf (commit)
   via  8d75d8dc72a0ac4502991891782a2c84df1f61c3 (commit)
  from  f45e3b950991f5c4f66cd132bda61a369a3016d7 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
---

Summary of changes:
 Modules/CMakeCUDAInformation.cmake |6 ++
 Modules/Compiler/NVIDIA-CUDA.cmake |2 +-
 Modules/Platform/Windows-NVIDIA-CUDA.cmake |2 ++
 Tests/Cuda/CMakeLists.txt  |1 +
 Tests/Cuda/WithC/CMakeLists.txt|   12 
 Tests/Cuda/WithC/cuda.cu   |   16 
 Tests/Cuda/WithC/main.c|   14 ++
 7 files changed, 52 insertions(+), 1 deletion(-)
 create mode 100644 Tests/Cuda/WithC/CMakeLists.txt
 create mode 100644 Tests/Cuda/WithC/cuda.cu
 create mode 100644 Tests/Cuda/WithC/main.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.8.0-rc1-172-g4e93e90

2017-02-15 Thread 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  4e93e9036ad904278b1634e082dbc627aea868e8 (commit)
   via  72cfb3c3d2e8f6167cf08289691f7b0c61d0d331 (commit)
   via  272c348d5a1c3f713586e05e0d73fd18441f7bb2 (commit)
   via  81ebf4be3eeabe7f1fc42929b3cc46e515fd4800 (commit)
  from  85cb9195338bfb9a3db0f3a4c60fe031599172eb (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=4e93e9036ad904278b1634e082dbc627aea868e8
commit 4e93e9036ad904278b1634e082dbc627aea868e8
Merge: 85cb919 72cfb3c
Author: Brad King 
AuthorDate: Wed Feb 15 08:25:52 2017 -0500
Commit: Brad King 
CommitDate: Wed Feb 15 08:25:52 2017 -0500

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.8.0-rc1-102-g72cfb3c

2017-02-15 Thread 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  72cfb3c3d2e8f6167cf08289691f7b0c61d0d331 (commit)
   via  272c348d5a1c3f713586e05e0d73fd18441f7bb2 (commit)
   via  81ebf4be3eeabe7f1fc42929b3cc46e515fd4800 (commit)
  from  8ff87662325b2f2c21600da03fb78bca142c (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, master, updated. v3.8.0-rc1-89-g8ba5c21

2017-02-15 Thread 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  8ba5c21db774cb23d223612ba67963723010e9f3 (commit)
   via  59ed323d4648a61d911679190273c35f950e20ce (commit)
  from  75040fc103b763092e54274d088659da792e72e8 (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=8ba5c21db774cb23d223612ba67963723010e9f3
commit 8ba5c21db774cb23d223612ba67963723010e9f3
Merge: 75040fc 59ed323
Author: Brad King 
AuthorDate: Wed Feb 15 08:24:02 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 15 08:24:02 2017 -0500

Merge topic 'cuda-no-Os'

59ed323d CUDA: Do not use non-existent -Os flag for nvcc


---

Summary of changes:
 Modules/Compiler/NVIDIA-CUDA.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.8.0-rc1-94-g99ca1e2

2017-02-15 Thread 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  99ca1e27e2453977d9b6e1b2a886c5b767fa9606 (commit)
   via  7c29a0c860c4bf92a941f6752e0b5c4ebf4c88f3 (commit)
  from  e853dfed6aef2dccc6bf05b6d19a5911e76f51c6 (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=99ca1e27e2453977d9b6e1b2a886c5b767fa9606
commit 99ca1e27e2453977d9b6e1b2a886c5b767fa9606
Merge: e853dfe 7c29a0c
Author: Brad King 
AuthorDate: Wed Feb 15 08:24:07 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 15 08:24:07 2017 -0500

Merge topic 'cuda-drop-comment'

7c29a0c8 CMakeDetermineCUDACompiler: Drop out-of-date comment


---

Summary of changes:
 Modules/CMakeDetermineCUDACompiler.cmake |7 ---
 1 file changed, 7 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.8.0-rc1-87-g75040fc

2017-02-15 Thread 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  75040fc103b763092e54274d088659da792e72e8 (commit)
   via  ff843dbd547d06b9dcb25c3970e857fe395f2dcf (commit)
   via  ced3396d048c8389327f661a99986fef51ee8a3f (commit)
  from  8b155a6c092d2b5e5355d6488fd7fa7e71f58207 (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=75040fc103b763092e54274d088659da792e72e8
commit 75040fc103b763092e54274d088659da792e72e8
Merge: 8b155a6 ff843db
Author: Brad King 
AuthorDate: Wed Feb 15 08:24:00 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 15 08:24:00 2017 -0500

Merge topic 'update-kwsys'

ff843dbd Merge branch 'upstream-KWSys' into update-kwsys
ced3396d KWSys 2017-02-14 (5c6f7836)


---

Summary of changes:
 Source/kwsys/SystemInformation.cxx|  246 +
 Source/kwsys/SystemInformation.hxx.in |2 +-
 2 files changed, 66 insertions(+), 182 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.8.0-rc1-92-ge853dfe

2017-02-15 Thread 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  e853dfed6aef2dccc6bf05b6d19a5911e76f51c6 (commit)
   via  1c60231ca546597ef8b80e7340c8991b06387cbf (commit)
   via  8d75d8dc72a0ac4502991891782a2c84df1f61c3 (commit)
  from  8ba5c21db774cb23d223612ba67963723010e9f3 (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=e853dfed6aef2dccc6bf05b6d19a5911e76f51c6
commit e853dfed6aef2dccc6bf05b6d19a5911e76f51c6
Merge: 8ba5c21 1c60231
Author: Brad King 
AuthorDate: Wed Feb 15 08:24:05 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 15 08:24:05 2017 -0500

Merge topic 'cuda-with-c'

1c60231c CUDA: Link to standard system libraries when linking as CUDA
8d75d8dc Tests: Add case for CUDA with C but not C++


---

Summary of changes:
 Modules/CMakeCUDAInformation.cmake |6 ++
 Modules/Platform/Windows-NVIDIA-CUDA.cmake |2 ++
 Tests/Cuda/CMakeLists.txt  |1 +
 Tests/Cuda/WithC/CMakeLists.txt|   12 
 Tests/Cuda/WithC/cuda.cu   |   16 
 Tests/Cuda/WithC/main.c|   14 ++
 6 files changed, 51 insertions(+)
 create mode 100644 Tests/Cuda/WithC/CMakeLists.txt
 create mode 100644 Tests/Cuda/WithC/cuda.cu
 create mode 100644 Tests/Cuda/WithC/main.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.8.0-rc1-96-g6a5e5a9

2017-02-15 Thread 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  6a5e5a926817f7318a2a80822aa2ce28674344f4 (commit)
   via  f7e5c6820a6eed8e6f29f7a5634a30b4f42a43aa (commit)
  from  99ca1e27e2453977d9b6e1b2a886c5b767fa9606 (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=6a5e5a926817f7318a2a80822aa2ce28674344f4
commit 6a5e5a926817f7318a2a80822aa2ce28674344f4
Merge: 99ca1e2 f7e5c68
Author: Brad King 
AuthorDate: Wed Feb 15 08:24:10 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 15 08:24:10 2017 -0500

Merge topic 'vs-dedup-tag'

f7e5c682 VS: De-duplicate PreprocessorDefinitions tag name


---

Summary of changes:
 Source/cmVisualStudioGeneratorOptions.cxx |   10 +-
 1 file changed, 5 insertions(+), 5 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.8.0-rc1-99-g8ff8766

2017-02-15 Thread 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  8ff87662325b2f2c21600da03fb78bca142c (commit)
   via  8ba6dc362dd1c5b073c68f8a873a91ddd2743e34 (commit)
   via  1d04d2ce3609da4c4f8d59ccfabd8848a6e765d4 (commit)
  from  6a5e5a926817f7318a2a80822aa2ce28674344f4 (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=8ff87662325b2f2c21600da03fb78bca142c
commit 8ff87662325b2f2c21600da03fb78bca142c
Merge: 6a5e5a9 8ba6dc3
Author: Brad King 
AuthorDate: Wed Feb 15 08:24:13 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 15 08:24:13 2017 -0500

Merge topic 'vs-refactor-libs'

8ba6dc36 VS: Place CMAKE__STANDARD_LIBRARIES after other libraries
1d04d2ce VS: Refactor parsing of CMAKE__STANDARD_LIBRARIES


---

Summary of changes:
 Source/cmVisualStudio10TargetGenerator.cxx |   28 
 1 file changed, 8 insertions(+), 20 deletions(-)


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

Re: [CMake] Intel C Generator for Cmake?

2017-02-15 Thread Tony Garratt

Re: my previous email. To use the Intel C compilers I just can modify the
VS settings. So I have a way forward.

Regards,
Tony

On Wed, Feb 15, 2017 at 12:25 PM, Petr Kmoch  wrote:

> Hi Tony,
>
> generators are for different *buildsystems*: a generator for Makefiles, a
> generator for Visual Studio solutions, a generator for Ninja files, a
> generator for Eclipse projects etc.
>
> Intel C and Intel Fortran are compilers, not buildsystems. You should be
> able to use them with any generator whose buildsystem supports those
> compilers.
>
> On Windows, CMake supports generation of vfproj files using the Visual
> Studio generator. I don't know if Intel C has its own Visual Studio project
> type in the same fashion, and if so, whether CMake supports it.
>
> One of the setups I maintain uses Visual Studio's C++ compiler and Intel
> Fortran compiler on Windows using the Visual Studio generator, and
> conceptually, it's as simple as this:
>
> call ...\ifortvars.bat ...
> set FC=ifort
> cmake ...
>
> Petr
>
> On 15 February 2017 at 12:34, Tony Garratt  wrote:
>
>> I am having to switch to cmake from autotools for a third party tool I
>> want to build. We use Intel C and Intel Fortran on Windows. I see no
>> mention of an Intel C generator for cmake. I presume this means there is
>> not one? If so, can I create my own Intel C generator please?
>>
>> Rgeards,
>> Tony
>>
>> --
>> *Dr Tony Garratt*
>>
>>
>


-- 
*Dr Tony Garratt*
Tel: +44 7624 309933
-- 

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] import external library

2017-02-15 Thread Wagner Martin

Hi @all,

I’ve tried importing an external library like that: 
stackoverflow.com/questions/31274577

I have the same use case, except that my custom target does not call make but 
does unpack a tar archive containing headers and .a.
My problem is that the step
“
# specify where the library is and where to find the headers
set_target_properties(lib2
PROPERTIES
IMPORTED_LOCATION ${LIB_FILE}
INTERFACE_INCLUDE_DIRECTORIES ${LIB_HEADER_FOLDER})
“
fails. When running cmake, I get an error that the header dir specified with 
“INTERFACE_INCLUDE_DIRECTORIES” does not exist.
“
CMake Error in src/CMakeLists.txt:
  Imported target "whatever" includes non-existent path

"/path/to/include"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

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

  * An install or uninstall procedure did not complete successfully.

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

This is true, as the header path is only generated when running the unpack 
target. Is there a way to tell cmake to skip this check?

Thanks!

Regards,
Martin




-- 

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.8.0-rc1-160-g258250c

2017-02-15 Thread 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  258250c4452bf6d73a0065d5914ce55360603d84 (commit)
   via  f773933f2630a17ce6b3b2aa6f8d7d8b65eb336c (commit)
   via  d9e2b9a909b5f5b51ef3a106ed1d60a8d4cb795a (commit)
  from  c4977015291e195193f0e529d86ebc039e009907 (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=258250c4452bf6d73a0065d5914ce55360603d84
commit 258250c4452bf6d73a0065d5914ce55360603d84
Merge: c497701 f773933
Author: Brad King 
AuthorDate: Wed Feb 15 08:17:34 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 15 08:17:34 2017 -0500

Merge topic 'vs-refactor-toolset-parsing' into next

f773933f VS: Refactor generator toolset parsing
d9e2b9a9 Tests: Split out RunCMake.GeneratorToolset Xcode checks


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f773933f2630a17ce6b3b2aa6f8d7d8b65eb336c
commit f773933f2630a17ce6b3b2aa6f8d7d8b65eb336c
Author: Brad King 
AuthorDate: Wed Feb 8 15:25:23 2017 -0500
Commit: Brad King 
CommitDate: Wed Feb 15 08:15:37 2017 -0500

VS: Refactor generator toolset parsing

We parse `CMAKE_GENERATOR_TOOLSET` values of the forms:

* `toolset`
* `toolset,host=x64`
* `host=x64`

Generalize the parsing to support the forms:

* `toolset`
* `toolset[,key=value]*`
* `key=value[,key=value]*`

Disallow duplicate keys.  Require all but the first field to
be of `key=value` form.

diff --git a/Source/cmGlobalVisualStudio10Generator.cxx 
b/Source/cmGlobalVisualStudio10Generator.cxx
index b64ae26..b1285ac 100644
--- a/Source/cmGlobalVisualStudio10Generator.cxx
+++ b/Source/cmGlobalVisualStudio10Generator.cxx
@@ -182,24 +182,80 @@ bool cmGlobalVisualStudio10Generator::SetGeneratorToolset(
 bool cmGlobalVisualStudio10Generator::ParseGeneratorToolset(
   std::string const& ts, cmMakefile* mf)
 {
-  if (ts.find_first_of(",=") != ts.npos) {
-std::ostringstream e;
-/* clang-format off */
-e <<
-  "Generator\n"
-  "  " << this->GetName() << "\n"
-  "does not recognize the toolset\n"
-  "  " << ts << "\n"
-  "that was specified.";
-/* clang-format on */
-mf->IssueMessage(cmake::FATAL_ERROR, e.str());
-return false;
+  std::vector const fields = cmSystemTools::tokenize(ts, ",");
+  std::vector::const_iterator fi = fields.begin();
+  if (fi == fields.end()) {
+return true;
+  }
+
+  // The first field may be the VS platform toolset.
+  if (fi->find('=') == fi->npos) {
+this->GeneratorToolset = *fi;
+++fi;
+  }
+
+  std::set handled;
+
+  // The rest of the fields must be key=value pairs.
+  for (; fi != fields.end(); ++fi) {
+std::string::size_type pos = fi->find('=');
+if (pos == fi->npos) {
+  std::ostringstream e;
+  /* clang-format off */
+  e <<
+"Generator\n"
+"  " << this->GetName() << "\n"
+"given toolset specification\n"
+"  " << ts << "\n"
+"that contains a field after the first ',' with no '='."
+;
+  /* clang-format on */
+  mf->IssueMessage(cmake::FATAL_ERROR, e.str());
+  return false;
+}
+std::string const key = fi->substr(0, pos);
+std::string const value = fi->substr(pos + 1);
+if (!handled.insert(key).second) {
+  std::ostringstream e;
+  /* clang-format off */
+  e <<
+"Generator\n"
+"  " << this->GetName() << "\n"
+"given toolset specification\n"
+"  " << ts << "\n"
+"that contains duplicate field key '" << key << "'."
+;
+  /* clang-format on */
+  mf->IssueMessage(cmake::FATAL_ERROR, e.str());
+  return false;
+}
+if (!this->ProcessGeneratorToolsetField(key, value)) {
+  std::ostringstream e;
+  /* clang-format off */
+  e <<
+"Generator\n"
+"  " << this->GetName() << "\n"
+"given toolset specification\n"
+"  " << ts << "\n"
+"that contains invalid field '" << *fi << "'."
+;
+  /* clang-format on */
+  mf->IssueMessage(cmake::FATAL_ERROR, e.str());
+  return false;
+}
   }
 
-  this->GeneratorToolset = ts;
   return true;
 }
 
+bool cmGlobalVisualStudio10Generator::ProcessGeneratorToolsetField(
+  std::string const& key, std::string const& value)
+{
+  static_cast(key);
+  static_cast(value);
+  return false;
+}
+
 bool cmGlobalVisualStudio10Generator::InitializeSystem(cmMakefile* mf)
 {
   if (this->SystemName == "Windows") {
diff --git

[Cmake-commits] CMake branch, next, updated. v3.8.0-rc1-157-gc497701

2017-02-15 Thread 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  c4977015291e195193f0e529d86ebc039e009907 (commit)
   via  db86099f386b59ed8fe0b66d1956454de14aede8 (commit)
  from  60c0bb2d4a7390ce63237da1b6a3d5dfcc79bab6 (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=c4977015291e195193f0e529d86ebc039e009907
commit c4977015291e195193f0e529d86ebc039e009907
Merge: 60c0bb2 db86099
Author: Brad King 
AuthorDate: Wed Feb 15 08:16:43 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 15 08:16:43 2017 -0500

Merge topic 'vs-refactor-toolset-parsing' into next

db86099f fixup! VS: Refactor generator toolset parsing


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=db86099f386b59ed8fe0b66d1956454de14aede8
commit db86099f386b59ed8fe0b66d1956454de14aede8
Author: Brad King 
AuthorDate: Wed Feb 15 08:10:11 2017 -0500
Commit: Brad King 
CommitDate: Wed Feb 15 08:10:11 2017 -0500

fixup! VS: Refactor generator toolset parsing

diff --git a/Tests/RunCMake/GeneratorToolset/BadToolsetHostArchXcode-result.txt 
b/Tests/RunCMake/GeneratorToolset/BadToolsetHostArchXcode-result.txt
new file mode 100644
index 000..d00491f
--- /dev/null
+++ b/Tests/RunCMake/GeneratorToolset/BadToolsetHostArchXcode-result.txt
@@ -0,0 +1 @@
+1
diff --git a/Tests/RunCMake/GeneratorToolset/BadToolsetHostArchXcode-stderr.txt 
b/Tests/RunCMake/GeneratorToolset/BadToolsetHostArchXcode-stderr.txt
new file mode 100644
index 000..5737e95
--- /dev/null
+++ b/Tests/RunCMake/GeneratorToolset/BadToolsetHostArchXcode-stderr.txt
@@ -0,0 +1,10 @@
+CMake Error at CMakeLists.txt:[0-9]+ \(project\):
+  Generator
+
+.*
+
+  does not recognize the toolset
+
+Test Toolset,host=x6[45]
+
+  that was specified\.$
diff --git a/Tests/RunCMake/GeneratorToolset/BadToolsetHostArchXcode.cmake 
b/Tests/RunCMake/GeneratorToolset/BadToolsetHostArchXcode.cmake
new file mode 100644
index 000..2fc38e5
--- /dev/null
+++ b/Tests/RunCMake/GeneratorToolset/BadToolsetHostArchXcode.cmake
@@ -0,0 +1 @@
+message(FATAL_ERROR "This should not be reached!")
diff --git a/Tests/RunCMake/GeneratorToolset/RunCMakeTest.cmake 
b/Tests/RunCMake/GeneratorToolset/RunCMakeTest.cmake
index 902569d..44c67a2 100644
--- a/Tests/RunCMake/GeneratorToolset/RunCMakeTest.cmake
+++ b/Tests/RunCMake/GeneratorToolset/RunCMakeTest.cmake
@@ -3,7 +3,7 @@ include(RunCMake)
 set(RunCMake_GENERATOR_TOOLSET "")
 run_cmake(NoToolset)
 
-if("${RunCMake_GENERATOR}" MATCHES "Visual Studio 1[01245]|Xcode" AND NOT 
XCODE_BELOW_3)
+if("${RunCMake_GENERATOR}" MATCHES "Visual Studio 1[01245]")
   set(RunCMake_GENERATOR_TOOLSET "Test Toolset")
   run_cmake(TestToolset)
   if("${RunCMake_GENERATOR}" MATCHES "Visual Studio 1[245]")
@@ -25,6 +25,11 @@ if("${RunCMake_GENERATOR}" MATCHES "Visual Studio 
1[01245]|Xcode" AND NOT XCODE_
   endif()
   set(RunCMake_GENERATOR_TOOLSET "Test Toolset,not_a_key")
   run_cmake(BadToolsetFormat)
+elseif("${RunCMake_GENERATOR}" STREQUAL "Xcode" AND NOT XCODE_BELOW_3)
+  set(RunCMake_GENERATOR_TOOLSET "Test Toolset")
+  run_cmake(TestToolset)
+  set(RunCMake_GENERATOR_TOOLSET "Test Toolset,host=x64")
+  run_cmake(BadToolsetHostArchXcode)
 else()
   set(RunCMake_GENERATOR_TOOLSET "Bad Toolset")
   run_cmake(BadToolset)

---

Summary of changes:
 .../BadToolsetHostArchXcode-result.txt} |0
 ...etHostArch-stderr.txt => BadToolsetHostArchXcode-stderr.txt} |4 ++--
 .../BadToolsetHostArchXcode.cmake}  |0
 Tests/RunCMake/GeneratorToolset/RunCMakeTest.cmake  |7 ++-
 4 files changed, 8 insertions(+), 3 deletions(-)
 copy Tests/RunCMake/{Android/BadSYSROOT-result.txt => 
GeneratorToolset/BadToolsetHostArchXcode-result.txt} (100%)
 copy Tests/RunCMake/GeneratorToolset/{BadToolsetHostArch-stderr.txt => 
BadToolsetHostArchXcode-stderr.txt} (56%)
 copy Tests/RunCMake/{GeneratorPlatform/BadPlatform.cmake => 
GeneratorToolset/BadToolsetHostArchXcode.cmake} (100%)


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

Re: [CMake] Intel C Generator for Cmake?

2017-02-15 Thread Tony Garratt

I tried setting the FC and CC variables and yet cmake still wants to use
the Microsoft compiler (BTW what I am building is the CGNS - the CFD common
file format).

Is there something I am missing?

CGNS_Build>set CC=icc

CGNS_Build>set FC=ifort

CGNS_Build>set CC
CC=icc

CGNS_Build>set FC
FC=ifort

CGNS_Build>cmake   -D CMAKE_C_COMPILER:PATH=$CC   -D
CMAKE_CXX_COMPILER:STRING=$CC   -D CMAKE
_Fortran_COMPILER:PATH=$FC   -D CMAKE_BUILD_TYPE:STRING="Release"   -D
CGNS_BUILD_SHARED:BOOL=ON   -D CGNS_ENABLE_LEGACY=ON   -D CGNS_BUIL
DCGNSTOOLS:BOOL=OFF..\src
-- Building for: Visual Studio 12 2013
-- The C compiler identification is MSVC 18.0.40629.0
-- The CXX compiler identification is MSVC 18.0.40629.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Warning (dev) at tools/CMakeLists.txt:6 (link_directories):
  This command specifies the relative path

On Wed, Feb 15, 2017 at 12:25 PM, Petr Kmoch  wrote:

> Hi Tony,
>
> generators are for different *buildsystems*: a generator for Makefiles, a
> generator for Visual Studio solutions, a generator for Ninja files, a
> generator for Eclipse projects etc.
>
> Intel C and Intel Fortran are compilers, not buildsystems. You should be
> able to use them with any generator whose buildsystem supports those
> compilers.
>
> On Windows, CMake supports generation of vfproj files using the Visual
> Studio generator. I don't know if Intel C has its own Visual Studio project
> type in the same fashion, and if so, whether CMake supports it.
>
> One of the setups I maintain uses Visual Studio's C++ compiler and Intel
> Fortran compiler on Windows using the Visual Studio generator, and
> conceptually, it's as simple as this:
>
> call ...\ifortvars.bat ...
> set FC=ifort
> cmake ...
>
> Petr
>
> On 15 February 2017 at 12:34, Tony Garratt  wrote:
>
>> I am having to switch to cmake from autotools for a third party tool I
>> want to build. We use Intel C and Intel Fortran on Windows. I see no
>> mention of an Intel C generator for cmake. I presume this means there is
>> not one? If so, can I create my own Intel C generator please?
>>
>> Rgeards,
>> Tony
>>
>> --
>> *Dr Tony Garratt*
>>
>>
>


-- 
*Dr Tony Garratt*
Tel: +44 7624 309933
-- 

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] Intel C Generator for Cmake?

2017-02-15 Thread Tony Garratt

Thank you so much Petr. I am new to cmake so did quite understand how
everything fits together. I will give your suggestion a try.

Regards,
Tony

On Wed, Feb 15, 2017 at 12:25 PM, Petr Kmoch  wrote:

> Hi Tony,
>
> generators are for different *buildsystems*: a generator for Makefiles, a
> generator for Visual Studio solutions, a generator for Ninja files, a
> generator for Eclipse projects etc.
>
> Intel C and Intel Fortran are compilers, not buildsystems. You should be
> able to use them with any generator whose buildsystem supports those
> compilers.
>
> On Windows, CMake supports generation of vfproj files using the Visual
> Studio generator. I don't know if Intel C has its own Visual Studio project
> type in the same fashion, and if so, whether CMake supports it.
>
> One of the setups I maintain uses Visual Studio's C++ compiler and Intel
> Fortran compiler on Windows using the Visual Studio generator, and
> conceptually, it's as simple as this:
>
> call ...\ifortvars.bat ...
> set FC=ifort
> cmake ...
>
> Petr
>
> On 15 February 2017 at 12:34, Tony Garratt  wrote:
>
>> I am having to switch to cmake from autotools for a third party tool I
>> want to build. We use Intel C and Intel Fortran on Windows. I see no
>> mention of an Intel C generator for cmake. I presume this means there is
>> not one? If so, can I create my own Intel C generator please?
>>
>> Rgeards,
>> Tony
>>
>> --
>> *Dr Tony Garratt*
>>
>>
>


-- 
*Dr Tony Garratt*
Tel: +44 7624 309933
-- 

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] Intel C Generator for Cmake?

2017-02-15 Thread Petr Kmoch

Hi Tony,

generators are for different *buildsystems*: a generator for Makefiles, a
generator for Visual Studio solutions, a generator for Ninja files, a
generator for Eclipse projects etc.

Intel C and Intel Fortran are compilers, not buildsystems. You should be
able to use them with any generator whose buildsystem supports those
compilers.

On Windows, CMake supports generation of vfproj files using the Visual
Studio generator. I don't know if Intel C has its own Visual Studio project
type in the same fashion, and if so, whether CMake supports it.

One of the setups I maintain uses Visual Studio's C++ compiler and Intel
Fortran compiler on Windows using the Visual Studio generator, and
conceptually, it's as simple as this:

call ...\ifortvars.bat ...
set FC=ifort
cmake ...

Petr

On 15 February 2017 at 12:34, Tony Garratt  wrote:

> I am having to switch to cmake from autotools for a third party tool I
> want to build. We use Intel C and Intel Fortran on Windows. I see no
> mention of an Intel C generator for cmake. I presume this means there is
> not one? If so, can I create my own Intel C generator please?
>
> Rgeards,
> Tony
>
> --
> *Dr Tony Garratt*
>
>
-- 

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] Intel C Generator for Cmake?

2017-02-15 Thread Tony Garratt

I am having to switch to cmake from autotools for a third party tool I want
to build. We use Intel C and Intel Fortran on Windows. I see no mention of
an Intel C generator for cmake. I presume this means there is not one? If
so, can I create my own Intel C generator please?

Rgeards,
Tony

-- 
*Dr Tony Garratt*
-- 

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] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...

2017-02-15 Thread Nils Gladitz


On 14.02.2017 22:53, Malfettone, Kris wrote:


If so, are executables named “test” no longer supported?
Am I missing something or wrong in some way?



Issues existed before 3.0 but since 3.0 "test" and similarly problematic 
target names have been explicitly reserved.


Any CMake Version >= 3.0 will issue a warning (when the required version 
is < 3.0) or an error (when the required version is >= 3.0) by default:

https://cmake.org/cmake/help/v3.8/policy/CMP0037.html

Nils
-- 

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

43 matches

Mail list logo