[Cmake-commits] CMake branch, master, updated. v3.9.1-456-ge4f16a0

[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  e4f16a06ab1cf0ded2e2dd484206ec57d8f60594 (commit)
  from  c47c011c77bfd1bfb8d2060511a2b957ce181c62 (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=e4f16a06ab1cf0ded2e2dd484206ec57d8f60594
commit e4f16a06ab1cf0ded2e2dd484206ec57d8f60594
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Sat Aug 12 00:01:12 2017 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Sat Aug 12 00:01:12 2017 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 7f35a7a..0bbb218 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 9)
-set(CMake_VERSION_PATCH 20170811)
+set(CMake_VERSION_PATCH 20170812)
 #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

Re: [CMake] FindIce module and C++11

[Roger Leigh]

On 11/08/17 20:15, Rolf Eike Beer wrote:

Am Donnerstag, 10. August 2017, 10:28:31 schrieb rle...@codelibre.net:

On 2017-08-10 09:50, Jones J.W. wrote:

I'm building my code on Linux using the g++ flags "-std=c++11". This
means that I must link with the libIce++11 libraries instead of
libIce.

The FindIce module, however as no provision for choosing these
libraries thus resulting in unresolved symbols at link time.

I tried getting around the problem by simply listing Ice++11 as a
COMPONENT which works in Linux but the same CMakeLists.txt file in
Windows won't work as there is no Ice++11. Currently I have resolved
this by having two calls to the FindIce module inside an IF( MSVC )
conditional.

Would it be possible to add a flag to tell the FindIce module whether
C++11 is being used or not?


FindIce certainly needs an update for Ice 3.7.


To me this smells like an imported target with a generator expression that
uses the C++11 or other lib depending on the used interface of the target. No
idea if that is possible, but that would be the direction I would search in.


I'm unsure, but I suspect it's not appropriate.  I'm currently treating 
them as separate libraries because whether C++11 is used by the compiler 
is orthogonal to whether you're using the C++11 Ice API (and code 
generator).  Ice generates language-specific interfaces and 
implementations from abstract definitions, and it treats C++ and C++11 
as essentially different languages.  You need to explicitly opt into 
using C++11 in the interface definitions for code generation, and with 
respect to which libraries you link to.


For anyone using Ice who would like to test, I've opened
  https://gitlab.kitware.com/cmake/cmake/merge_requests/1137for testing 
and review.  Would be helpful if anyone wanting to use Ice 3.7 could 
give it a try, but equally if you're using 3.[3456] it would be great to 
know if there are any regressions.  I'll be testing Ice 3.5, but no 
longer have any of the others lying around (3.3 can probably be removed, 
it's so old and unsupported).



Regards,
Roger
--

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] FindIce module and C++11

[Rolf Eike Beer]

Am Donnerstag, 10. August 2017, 10:28:31 schrieb rle...@codelibre.net:
> On 2017-08-10 09:50, Jones J.W. wrote:
> > I'm building my code on Linux using the g++ flags "-std=c++11". This
> > means that I must link with the libIce++11 libraries instead of
> > libIce.
> > 
> > The FindIce module, however as no provision for choosing these
> > libraries thus resulting in unresolved symbols at link time.
> > 
> > I tried getting around the problem by simply listing Ice++11 as a
> > COMPONENT which works in Linux but the same CMakeLists.txt file in
> > Windows won't work as there is no Ice++11. Currently I have resolved
> > this by having two calls to the FindIce module inside an IF( MSVC )
> > conditional.
> > 
> > Would it be possible to add a flag to tell the FindIce module whether
> > C++11 is being used or not?
> 
> FindIce certainly needs an update for Ice 3.7.

To me this smells like an imported target with a generator expression that 
uses the C++11 or other lib depending on the used interface of the target. No 
idea if that is possible, but that would be the direction I would search in.

Greetings,

Eike

signature.asc
Description: This is a digitally signed message part.
-- 

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] FindIce module and C++11

[rleigh]

On 2017-08-10 10:28, rle...@codelibre.net wrote:

On 2017-08-10 09:50, Jones J.W. wrote:

I'm building my code on Linux using the g++ flags "-std=c++11". This
means that I must link with the libIce++11 libraries instead of
libIce.

The FindIce module, however as no provision for choosing these
libraries thus resulting in unresolved symbols at link time.

I tried getting around the problem by simply listing Ice++11 as a
COMPONENT which works in Linux but the same CMakeLists.txt file in
Windows won't work as there is no Ice++11. Currently I have resolved
this by having two calls to the FindIce module inside an IF( MSVC )
conditional.


Looking at the NuGet packages, I can see Ice++11 on Windows; it's named 
Ice37++11[d].lib.  Helpfully not following the existing conventions on 
the other platforms and previous Ice releases, but I think I've worked 
around this now.



Would it be possible to add a flag to tell the FindIce module whether
C++11 is being used or not?


FindIce certainly needs an update for Ice 3.7.

Regarding C++11, their approach here is certainly a bit unorthodox as
well as being inconsistent between platforms, and FindIce will need to
deal with that unfortunate situation.  Since the old and new APIs are
incompatible, and you have to explicitly opt-in to using the new one,
I don't think that using "-std=c++11" on its own is sufficient reason
to select the C++11 library?  Can you use the old API with a C++11
compiler?  It might be best to have a set of C++11 component names,
and map these to the appropriate library names on Linux (separate
libs) and Windows (not separate), if that would make the intent of the
user clear and unambiguous.

I will try to look at this, but I'm a little busy with other things at
the moment, and so it's not at top of my list.  If you wanted to
propose a change an/or open a merge request that would certainly be
welcome.


I have done some preliminary work here:

  https://gitlab.kitware.com/rleigh/cmake/commits/ice-3.7.0

It's working on Linux, but not yet finding the libraries on Windows when 
using the NuGet distribution of the libraries.  This is likely some 
minor bug which I need to identify; it's using all the correct paths and 
suffixes that I can see.


If you would like to give this a go and help fix the detection on 
Windows, that would be really helpful.  I've left some extra debugging 
messages in to trace how find_library is working.  If you set 
CMAKE_PREFIX_PATH to the location where the NuGet packages live, it 
should automatically detect the package name.  Do we have any existing 
conventions within CMake for finding libraries within such packages?  
Should the package be listed specifically on CMAKE_PREFIX_PATH, or is 
finding the package itself on the path acceptable?  Or should both be 
supported?



Regards,
Roger

--

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] Possible bug/incompatibility FindCUDA with Visual Studio 2017

[Andrea Borsic]

Hi,

Thanks for your pointers, problem solved.

I have upgraded to CMake 3.9.1 (I don't think this matters though) and I 
switched to using the new CUDA CMake support as at your point 3). I am 
also using CUDA 9 RC which supports VS2017 (I was testing under CUDA 8 / 
CUDA 9 earlier, but just forgot to mention this). Now all builds 
successfully.


I am attaching the updated CMakeLists.txt file for the record.

Thanks, Best Regards,

Andrea



On 8/10/2017 4:28 PM, Robert Maynard wrote:

So you are going to have two issues.

1. The FindCUDA module has not been updated to handle VS2017. The
issue is that the VCInstallDir variable now returns a different
relative path to the compiler than it previously did. If you can
determine the new logic a patch fixing this behavior be great.

2. It doesn't look like CUDA 8.0 supports VS2017 (
http://docs.nvidia.com/cuda/cuda-installation-guide-microsoft-windows/index.html#system-requirements
).

3. You could also look at using the new CMake 3.9 cuda support (
https://devblogs.nvidia.com/parallelforall/building-cuda-applications-cmake/
).

On Thu, Aug 10, 2017 at 5:49 AM, Andrea Borsic  wrote:

Hi All,

I am working on this platform:

Windows 10 64bit
Visual Studio 2015 Community Edition
Visual Studio 2017 Community Edition
CUDA 8.0
CMake 3.9

I am in the middle of switching from VS2015 to VS2017, but CUDA projects
fail to properly compile under VS2017 as the compiler/linker fail to find
tools on the path setup by CMake. I believe this is bug/incompatibly of the
CMake FindCUDA module with VS2017.

To reproduce the problem I am attaching a tiny project

main.cu is a minimal CUDA example from the web
CMakeLists.txt is a CMake file that leads to a successful build under VS2015
and unsuccessful under VS2017
Output VS2015 is the output from building the project under VS2015 (all
targets built OK)
Output VS2017 is the output from building the project under VS2015 (1 target
OK one target fails)

I have noticed also that oddly under VS2017 an "x64" and "main.dir"
directories are created outside the build dir, and at the level of the
source directory.

I thought of reporting this to the list, and any help is welcome,

Thank you and Best Regards,

Andrea


--

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


#include 

//
// Nearly minimal CUDA example.
// Compile with:
//
// nvcc -o example example.cu
//

#define N 1000

//
// A function marked __global__
// runs on the GPU but can be called from
// the CPU.
//
// This function multiplies the elements of an array
// of ints by 2.
//
// The entire computation can be thought of as running
// with one thread per array element with blockIdx.x
// identifying the thread.
//
// The comparison i>>(da, db);

//
// Copy output array from GPU back to CPU.
//
cudaMemcpy(hb, db, N*sizeof(int), cudaMemcpyDeviceToHost);

for (int i = 0; i

Re: [cmake-developers] Developing Compiler files.

[Валентин Хирный]

Hello.
Yes, the bcc32 is provided by Borland and has Borland options and the bcc64
provided by Embarcadero and it is clang based and has Clang options but
with old linker.
The bcc32c is provided by Embarcadero and it is clang based but has Borland
options wrapper.

Actually I don't interested in Embarcadero itself but in content of files
placed in the .../Modules/Platform folder.
And search some usefully info about the cmake options passed to compiler
and  linker.
Also I have tryed to find some info about this files but haven't found
anything about them.
Please share some links or docs if you have.

Thanks.
Valentyn.

On Aug 11, 2017 15:39, "Brad King"  wrote:

> On 08/11/2017 03:18 AM, Валентин Хирный wrote:
> > I've tried to prepare cmake configuration file for Embarcadero bcc64
> compiler.
> > For my practice I chose the name Embarcadero64 for new compiler because
> > bcc64 is clang based compiler.
>
> Does `bcc64` have a radically different command line interface from `bcc32`
> that justifies a separate compiler id?  I don't think we have a distinction
> in compiler id based on the target architecture for any other compiler.
>
> Thanks,
> -Brad
>
-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, master, updated. v3.9.1-455-gc47c011

[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  c47c011c77bfd1bfb8d2060511a2b957ce181c62 (commit)
   via  7983e068e176a0e3cffb3794d9665fb862614158 (commit)
  from  73657a35e6f64e530e8bbda90757c3762d7c36c6 (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=c47c011c77bfd1bfb8d2060511a2b957ce181c62
commit c47c011c77bfd1bfb8d2060511a2b957ce181c62
Merge: 73657a3 7983e06
Author: Brad King 
AuthorDate: Fri Aug 11 13:51:45 2017 +
Commit: Kitware Robot 
CommitDate: Fri Aug 11 09:51:54 2017 -0400

Merge topic 'github-pr-template'

7983e068 Add GitHub PR template to point contributors at CONTRIBUTING.rst

Acked-by: Kitware Robot 
Reviewed-by: Ben Boeckel 
Reviewed-by: Craig Scott 
Merge-request: !1125


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7983e068e176a0e3cffb3794d9665fb862614158
commit 7983e068e176a0e3cffb3794d9665fb862614158
Author: Brad King 
AuthorDate: Thu Aug 10 09:56:41 2017 -0400
Commit: Brad King 
CommitDate: Fri Aug 11 08:23:09 2017 -0400

Add GitHub PR template to point contributors at CONTRIBUTING.rst

GitHub's link to the contribution guidelines in `CONTRIBUTING.rst`
is not prominent enough to be reliably noticed and followed by
new contributors.  Add a PR template to make the link more visible.

diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
new file mode 100644
index 000..d934bf9
--- /dev/null
+++ b/.github/pull_request_template.md
@@ -0,0 +1,7 @@
+Thanks for your interest in contributing to CMake!  The GitHub repository
+is a mirror provided for convenience, but CMake does not use GitHub pull
+requests for contribution.  Please see
+
+  https://gitlab.kitware.com/cmake/cmake/tree/master/CONTRIBUTING.rst
+
+for contribution instructions.  GitHub OAuth may be used to sign in.

---

Summary of changes:
 .github/pull_request_template.md |7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 .github/pull_request_template.md


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

[CMake] OBJECT Libraries and linking against targets

[Wesley Smith]

Hi,
I understand vaguely why OBJECT libraries can't link against other targets,
but I don't think the restriction in place needs to be so constrained.
Consider the following:

* A target is being create as an OBJECT library
* A number of other targets are defined as INTERFACE target where they only
set include paths, compiler options, etc.

How is it possible to communicate the dependencies expressed in an
INTERFACE target to an OBJECT library?  So far the only method I've found
that works is to use a handful of generator expressions, which seems like a
lot of work for something that would just work if I could "link" the
INTERFACE library against the OBJECT library.

Here's what I have to do:

target_compile_features(tgt PUBLIC
$
)
target_include_directories(tgt PUBLIC
$
)
target_compile_options(tgt PUBLIC
$
$
)
target_compile_definitions(tgt PUBLIC
$
)

thanks!
wes
-- 

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.9.1-453-g73657a3

[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  73657a35e6f64e530e8bbda90757c3762d7c36c6 (commit)
   via  88c9878af9d6d4b8cd3c7358bfdd12206c8aadb4 (commit)
  from  1d51fcaeafeb9bfcdf3bc871d2b875446df081e8 (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=73657a35e6f64e530e8bbda90757c3762d7c36c6
commit 73657a35e6f64e530e8bbda90757c3762d7c36c6
Merge: 1d51fca 88c9878
Author: Brad King 
AuthorDate: Fri Aug 11 13:16:59 2017 +
Commit: Kitware Robot 
CommitDate: Fri Aug 11 09:17:04 2017 -0400

Merge topic 'libuv-required'

88c9878a Make libuv available to all parts of CMake

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=88c9878af9d6d4b8cd3c7358bfdd12206c8aadb4
commit 88c9878af9d6d4b8cd3c7358bfdd12206c8aadb4
Author: Brad King 
AuthorDate: Thu Aug 3 14:47:49 2017 -0400
Commit: Brad King 
CommitDate: Tue Aug 8 09:34:54 2017 -0400

Make libuv available to all parts of CMake

The libuv library provides many useful platform abstractions and better
process management than KWSys.  We'd like to use it everywhere instead
of just in the server mode.  Drop the `CMAKE_USE_LIBUV` option and use
libuv everywhere except during bootstrap.

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 831e25f..e60dc78 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -529,42 +529,21 @@ macro (CMAKE_BUILD_UTILITIES)
 
   #-
   # Build libuv library.
-  if(NOT DEFINED CMAKE_USE_LIBUV)
-set(CMAKE_USE_LIBUV 1)
-if(APPLE)
-  include(CheckCSourceCompiles)
-  check_c_source_compiles("
-#include 
-#include 
-#ifndef MAC_OS_X_VERSION_10_5
-#error \"MAC_OS_X_VERSION_10_5 is not defined\"
-#endif
-int main(void) { return 0; }
-" HAVE_CoreServices_OS_X_10_5)
-  if(NOT HAVE_CoreServices_OS_X_10_5)
-set(CMAKE_USE_LIBUV 0)
-  endif()
-endif()
-  endif()
-  if(CMAKE_USE_LIBUV)
-if(CMAKE_USE_SYSTEM_LIBUV)
-  if(NOT CMAKE_VERSION VERSION_LESS 3.0)
-find_package(LibUV 1.0.0)
-  else()
-message(FATAL_ERROR "CMAKE_USE_SYSTEM_LIBUV requires CMake >= 3.0")
-  endif()
-  if(NOT LIBUV_FOUND)
-message(FATAL_ERROR
-  "CMAKE_USE_SYSTEM_LIBUV is ON but a libuv is not found!")
-  endif()
-  set(CMAKE_LIBUV_LIBRARIES LibUV::LibUV)
+  if(CMAKE_USE_SYSTEM_LIBUV)
+if(NOT CMAKE_VERSION VERSION_LESS 3.0)
+  find_package(LibUV 1.0.0)
 else()
-  set(CMAKE_LIBUV_LIBRARIES cmlibuv)
-  add_subdirectory(Utilities/cmlibuv)
-  CMAKE_SET_TARGET_FOLDER(cmlibuv "Utilities/3rdParty")
+  message(FATAL_ERROR "CMAKE_USE_SYSTEM_LIBUV requires CMake >= 3.0")
 endif()
+if(NOT LIBUV_FOUND)
+  message(FATAL_ERROR
+"CMAKE_USE_SYSTEM_LIBUV is ON but a libuv is not found!")
+endif()
+set(CMAKE_LIBUV_LIBRARIES LibUV::LibUV)
   else()
-set(CMAKE_LIBUV_LIBRARIES)
+set(CMAKE_LIBUV_LIBRARIES cmlibuv)
+add_subdirectory(Utilities/cmlibuv)
+CMAKE_SET_TARGET_FOLDER(cmlibuv "Utilities/3rdParty")
   endif()
 
   #-
@@ -758,8 +737,7 @@ if(NOT CMake_TEST_EXTERNAL_CMAKE)
   if(NOT DEFINED CMake_ENABLE_SERVER_MODE)
 list(FIND CMAKE_CXX_COMPILE_FEATURES cxx_auto_type 
CMake_HAVE_CXX_AUTO_TYPE)
 list(FIND CMAKE_CXX_COMPILE_FEATURES cxx_range_for 
CMake_HAVE_CXX_RANGE_FOR)
-if(CMAKE_USE_LIBUV
-AND CMake_HAVE_CXX_AUTO_TYPE
+if(CMake_HAVE_CXX_AUTO_TYPE
 AND CMake_HAVE_CXX_MAKE_UNIQUE
 AND CMake_HAVE_CXX_RANGE_FOR
 )
@@ -768,9 +746,6 @@ if(NOT CMake_TEST_EXTERNAL_CMAKE)
   set(CMake_ENABLE_SERVER_MODE 0)
 endif()
   endif()
-  if(CMake_ENABLE_SERVER_MODE AND NOT CMAKE_USE_LIBUV)
-message(FATAL_ERROR "The server mode requires libuv!")
-  endif()
 else()
   set(CMake_ENABLE_SERVER_MODE 0)
 endif()
diff --git a/Source/cmConfigure.cmake.h.in b/Source/cmConfigure.cmake.h.in
index 524fdf8..302000a 100644
--- a/Source/cmConfigure.cmake.h.in
+++ b/Source/cmConfigure.cmake.h.in
@@ -19,7 +19,6 @@
 #cmakedefine HAVE_UNSETENV
 #cmakedefine CMAKE_USE_ELF_PARSER
 #cmakedefine CMAKE_USE_MACH_PARSER
-#cmakedefine CMAKE_USE_LIBUV
 #cmakedefine CMake_HAVE_CXX_AUTO_PTR
 #cmakedefine CMake_HAVE_CXX_EQ_DELETE
 #cmakedefine CMake_HAVE_CXX_FALLTHROUGH
diff --git a/Source/cmakemain.cxx b/Source/cmakemain.cxx
index c5a6836..dd88083 100644
--- 

[Cmake-commits] CMake branch, master, updated. v3.9.1-451-g1d51fca

[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  1d51fcaeafeb9bfcdf3bc871d2b875446df081e8 (commit)
   via  0baf114a35f061ac27f44c9d4716b2f30a1533c6 (commit)
   via  d4b70a20fae44e802b5e07c7fa18b81808263f77 (commit)
   via  485cbd456aae395da1661b08161751c3c3b47a96 (commit)
   via  eda45e9f17cdc401c6450d0e8eca65e5b068330f (commit)
   via  15ef27286ade97a49f6832254d3451755a824fb8 (commit)
   via  362f9bd755c7b964184db38d1fb2217ded70af63 (commit)
   via  952fc65d140a1b36fc2e580d7ca89de231a04412 (commit)
   via  cbf1393aa4b957ec3c2c5cc4852dcebab825c5b6 (commit)
   via  ae813b6bcc64fc5096fb4a7d87920b47cfbe488f (commit)
   via  d9c8aa47c2e7a2f97def22847a76c3cfcba74f01 (commit)
   via  4f7d9eef51da4a72fd7c7a17bcbbcf83ffad3216 (commit)
  from  f8a61c578badb0015423580b38341bc00a3c7fd4 (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=1d51fcaeafeb9bfcdf3bc871d2b875446df081e8
commit 1d51fcaeafeb9bfcdf3bc871d2b875446df081e8
Merge: 0baf114 15ef272
Author: Brad King 
AuthorDate: Fri Aug 11 13:14:36 2017 +
Commit: Kitware Robot 
CommitDate: Fri Aug 11 09:14:40 2017 -0400

Merge topic 'autogen-merge-redundant'

15ef2728 Autogen: Add test for OBJECT libraries
362f9bd7 Autogen: Merge and remove redundant function calls
952fc65d Autogen: Clear sources meta data cache

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0baf114a35f061ac27f44c9d4716b2f30a1533c6
commit 0baf114a35f061ac27f44c9d4716b2f30a1533c6
Merge: d4b70a2 4f7d9ee
Author: Brad King 
AuthorDate: Fri Aug 11 13:13:36 2017 +
Commit: Kitware Robot 
CommitDate: Fri Aug 11 09:13:39 2017 -0400

Merge topic 'genex-COMPILE_FEATURES-stds'

4f7d9eef Features: Fix COMPILE_FEATURES genex for C++ 14 and 17 features

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d4b70a20fae44e802b5e07c7fa18b81808263f77
commit d4b70a20fae44e802b5e07c7fa18b81808263f77
Merge: 485cbd4 ae813b6
Author: Brad King 
AuthorDate: Fri Aug 11 13:12:23 2017 +
Commit: Kitware Robot 
CommitDate: Fri Aug 11 09:12:37 2017 -0400

Merge topic 'FindCUDA-superseded'

ae813b6b FindCUDA: Document that module has been superseded

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=485cbd456aae395da1661b08161751c3c3b47a96
commit 485cbd456aae395da1661b08161751c3c3b47a96
Merge: eda45e9 d9c8aa4
Author: Brad King 
AuthorDate: Fri Aug 11 13:12:15 2017 +
Commit: Kitware Robot 
CommitDate: Fri Aug 11 09:12:18 2017 -0400

Merge topic 'findcuda_dont_ignore_CUDA_USE_STATIC_CUDA_RUNTIME'

d9c8aa47 FindCUDA: Always obey the CUDA_USE_STATIC_CUDA_RUNTIME option.

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eda45e9f17cdc401c6450d0e8eca65e5b068330f
commit eda45e9f17cdc401c6450d0e8eca65e5b068330f
Merge: f8a61c5 cbf1393
Author: Brad King 
AuthorDate: Fri Aug 11 13:11:37 2017 +
Commit: Kitware Robot 
CommitDate: Fri Aug 11 09:11:43 2017 -0400

Merge topic 'FindCUDA-cuda9'

cbf1393a FindCUDA: Add CUDA9/Volta recognition

Acked-by: Kitware Robot 
Reviewed-by: Robert Maynard 
Merge-request: !1119


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=15ef27286ade97a49f6832254d3451755a824fb8
commit 15ef27286ade97a49f6832254d3451755a824fb8
Author: Sebastian Holtermann 
AuthorDate: Thu Aug 10 19:16:16 2017 +0200
Commit: Sebastian Holtermann 
CommitDate: Thu Aug 10 23:15:48 2017 +0200

Autogen: Add test for OBJECT libraries

diff --git a/Tests/QtAutogen/CMakeLists.txt b/Tests/QtAutogen/CMakeLists.txt
index 5064d26..198bf63 100644
--- a/Tests/QtAutogen/CMakeLists.txt
+++ b/Tests/QtAutogen/CMakeLists.txt
@@ -193,5 +193,9 @@ endif()
 add_subdirectory(uicInclude)
 
 # -- Test
+# OBJECT libraries
+add_subdirectory(objectLibrary)
+
+# -- Test
 # Complex test case
 add_subdirectory(complex)
diff --git a/Tests/QtAutogen/objectLibrary/CMakeLists.txt 
b/Tests/QtAutogen/objectLibrary/CMakeLists.txt
new file mode 100644
index 

Re: [CMake] Append to property COMPILE_DEFINITIONS

[Petr Kmoch]

On 24 July 2017 at 04:32, Florian Lindner  wrote:

>
>
> [snip]
>
> Still, I don't undertand what is wrong with:
>
> set_property(GLOBAL APPEND PROPERTY COMPILE_DEFINITIONS
> $<$:-FOO>)
>
> ?
>

What's wrong is that there is no such global property. See the list of
global properties:
https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html#properties-of-global-scope

COMPILE_DEFINITIONS is not among them.

You're therefore effectively creating a new user-defined global property,
which of course has no effect on CMake's behaviour.

Petr
-- 

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] Developing Compiler files.

[Brad King]

On 08/11/2017 03:18 AM, Валентин Хирный wrote:
> I've tried to prepare cmake configuration file for Embarcadero bcc64 compiler.
> For my practice I chose the name Embarcadero64 for new compiler because
> bcc64 is clang based compiler.

Does `bcc64` have a radically different command line interface from `bcc32`
that justifies a separate compiler id?  I don't think we have a distinction
in compiler id based on the target architecture for any other compiler.

Thanks,
-Brad
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Referencing an OBJECT library

[Petr Kmoch]

Hi Edward.

"the reference to that OBJECT library is through $" -
that is not quite true. When you're referring to the object library target
itself (e.g. reading its properties), you use its name just like with any
other target:

  get_property(someVar TARGET xxx PROPERTY TYPE)

However, the genex $ is used when you're specifying
that the sources of another target yyy are to include the objects
comprising the object library xxx:

  add_executable(yyy main.cpp $)

Here, you're not dealing with the object library xxx itself, but with the
objects from which it's composed, so you're referring to these objects
explicitly. It's quite similar to how you'd use other properties of a
target:

  target_sources(yyy $)

would similarly add all sources of target xxx to the target yyy.

Petr

On 20 July 2017 at 22:57, Edward Diener 
wrote:

> According to the CMake docs for an OBJECT library called, let's say,
> 'xxx', the reference to that OBJECT library is through
> $. I understand this but I am curious about the reason
> for such syntax. After all a STATIC or SHARED library 'xxx' you can just
> use xxx to refer to the library. Why the difference in CMake syntax
> reference between OBJECT libraries added with the add_library command and
> STATIC or SHARED libraries added with the add_library command ?
>
> --
>
> 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/opensou
> rce/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] Platform dSPACE

[Robin Verschueren]

I've got a follow-up question about cross-compiling for dSpace. My
Toolchain file so far:

set(CMAKE_SYSTEM_NAME dSpace)
list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_LIST_DIR})

file(TO_CMAKE_PATH "C:\\Program Files\\dSPACE RCPHIL 2016-B" DSPACE_TOOLS)
set(DSPACE_PPCTOOLS ${DSPACE_TOOLS}/Compiler/PPCTools)

find_program(CMAKE_C_COMPILER NAMES ${DSPACE_PPCTOOLS}/bin/mccppc.exe)
find_program(CMAKE_C_COMPILER NAMES ${DSPACE_PPCTOOLS}/bin/cccppc.exe)

find_program(CMAKE_MAKE_PROGRAM ${DSPACE_TOOLS}/Exe/DSMAKE.EXE)

set(CMAKE_FIND_ROOT_PATH ${DSPACE_PPCTOOLS})

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

CMake is actually able to locate the C compiler (called "mccppc.exe") and
CMake thus tries to compile a test program ('CompilerIdC.c'). I can compile
this source file 'by hand' with said compiler. However, from CMake (which
automatically uses MSBuild.exe), I get the error output below.

How can I circumvent MSBuild.exe and/or the attempted loading of the SDK?
Do I forget to set some other important variables (e.g. CMAKE_MAKE_PROGRAM
seems to be ignored?)

The C compiler "C:/Program Files/dSPACE
RCPHIL 2016-B/Compiler/PPCTools/bin/mccppc.exe" is not able to compile a
simple test program.
  It fails with the following output:

Compiling the C compiler identification source file "CMakeCCompilerId.c"
failed.
Compiler: C:/Program Files/dSPACE RCPHIL
2016-B/Compiler/PPCTools/bin/mccppc.exe
Build flags:
Id flags:
The output was:
1
…

Microsoft (R) Build Engine version 15.1.1012.6693
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 8/11/2017 11:34:36 AM.
Project
"C:\Users\SYSCOP\Documents\GitHub\acados-master\build\CMakeFiles\3.8.2\CompilerIdC\CompilerIdC.vcxproj"
on node 1 (default targets).
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\Common7\IDE\VC\VCTargets\Platforms\Win32\PlatformToolsets\v141\Toolset.targets(34,5):
error MSB8036: The Windows SDK version 8.1 was not found. Install the
required version of Windows SDK or change the SDK version in the project
property pages or by right-clicking the solution and selecting "Retarget
solution".
[C:\Users\SYSCOP\Documents\GitHub\acados-master\build\CMakeFiles\3.8.2\CompilerIdC\CompilerIdC.vcxproj]
Done Building Project
"C:\Users\SYSCOP\Documents\GitHub\acados-master\build\CMakeFiles\3.8.2\CompilerIdC\CompilerIdC.vcxproj"
(default targets) -- FAILED.
Build FAILED.

On Fri, 23 Jun 2017 at 22:37 Robin Verschueren 
wrote:

> Dear Nils,
>
> Perfect! This was exactly what I was looking for.
> It works, and the CMAKE_INCLUDE_FLAG_C
> is not overwritten.
>
> Thanks,
> Robin
>
>
> On Fri, 23 Jun 2017 at 13:29 Nils Gladitz  wrote:
>
>> On 23.06.2017 21:47, Robin Verschueren wrote:
>>
>> Dear CMake,
>>
>> We are trying to build our application for the dSPACE embedded system
>> (www.dspace.com), more specifically their MicroAutobox-II. This makes
>> use of a specific compiler called mccppc (Microtec C/C++ PowerPC
>> compiler).
>>
>> I was following the instructions on this wiki page
>> , when I got the following
>> warning,
>> when trying to use a custom 'Toolchain' file:
>>
>> System is unknown to cmake, create:
>>
>> Platform/dSPACE to use this system, please send your config file to
>>
>> cm...@www.cmake.org so it can be added to cmake
>>
>> We would be glad to send it to you when it is finished, but in the
>> meantime,
>> we cannot debug our toolchain file because of above warning.
>>
>> Is there a way of including it without having to include it in the
>> official CMake
>> distribution? I tried setting CMAKE_MODULE_PATH but that did not help..
>>
>>
>> In the Toolchain file:
>> set(CMAKE_SYSTEM_NAME dSPACE)
>>
>> list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_LIST_DIR})
>>
>> ...
>>
>> Then having Platform/dSPACE.cmake next to your toolchain file should work
>> (works for me).
>>
>>
>> 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-developers] Developing Compiler files.

[Валентин Хирный]

Hello.
I've tried to prepare cmake configuration file for Embarcadero bcc64
compiler.
For my practice I chose the name Embarcadero64 for new compiler because
bcc64 is clang based compiler.
I've prepared file fo determining compiler in the
...\CMake\share\cmake-3.9\Modules\Compiler
folder (analog of theEmbarcadero-DetermineCompiler.cmake)
Then added my new compiler in an orderedcompilerlis in the
CMakeCompilerIdDetection.cmake.
And finally I created the Windows-Embarcadero64.cmake,
Windows-Embarcadero64-C.cmake end Windows-Embarcadero64-CXX.cmake
And get a lot of troubles with variables.

Please share some links to usefull resources about containing of files in
the
...\CMake\share\cmake-3.9\Modules\Platform\.
Thanks.

Best regards.
Valentyn
-- 

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