Re: [cmake-developers] C# support ready for review

[Gilles Khouzam]

Hi Michael,

Great work, this looks really good.

I have a few comments on the changes.


1.   You should use the registry to find the install path for MSBuild, it 
should be in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild with the 
version that you're looking for. This also bring the question of do you want to 
be able to specify the version of MSBuild that is used or base it off the 
generator?

2.   In CMakeTestCSharpCompiler, you seem to still have a reference to your 
specific user path (COPY_FILE 
"C:/Users/stuermic/git/cmake_build/x64_14/Tests/CSharp"))

You seem to have some slight discrepancies between your code and the release as 
there are changes that seem to be either unnecessary or going backwards. I 
noticed a tegra comment that seemed out of place as well as a comment change 
going from 14 to 12 where 14 was accurate.

I'll try to play with this next week and get projects running on it.

~Gilles

From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of 
Stuermer, Michael SP/HZA-ZSEP
Sent: Wednesday, February 10, 2016 06:03
To: CMake Developers 
Subject: [cmake-developers] C# support ready for review

Native C# support is ready for review. I split the patch in two parts:

part 1:

Some preparational stuff that does not really change or enable anything. 
Documentation and Test files as well as the required CMake module is added. The 
changes to existing code are small, only few methods in existing classes are 
added/changed. Changes to existing code should be easy to review in this part

part 2:

This contains the main work. Almost everything takes place within 
cmVisualStudio10TargetGenerator.


In addition to C# support three more target properties were introduced:

*   VS_USER_PROPS_CXX (allows use of custom .user.props MSBuild file in 
.vcxproj files)
*   VS_USER_PROPS_CSHARP (allows use of custom .user.props MSBuild file in 
.csproj files)
*   VS_DEBUGGER_WORKING_DIRECTORY (allows setting of debugger working 
directory in .vcxproj files)

I tested the features using Visual Studio 2010-2015 in 32/64 bit and everything 
works on my machine so far.

Please review/test/comment and give feedback what is necessary to get native C# 
support in upstream cmake.

best regards,
Michael


-- 

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.5.0-rc2-91-gede2a6e

[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  ede2a6ea6b6ff201ea1b2e2f7943b301a28b1df5 (commit)
  from  ed1b3430fcfc906780b68fe4a073590c6d23ff08 (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=ede2a6ea6b6ff201ea1b2e2f7943b301a28b1df5
commit ede2a6ea6b6ff201ea1b2e2f7943b301a28b1df5
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Thu Feb 18 00:01:04 2016 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Thu Feb 18 00:01:04 2016 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 533cff4..4b38a66 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 5)
-set(CMake_VERSION_PATCH 20160217)
+set(CMake_VERSION_PATCH 20160218)
 #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-developers] [Qt-creator] CMake daemon for user tools

[Milian Wolff]

On Mittwoch, 17. Februar 2016 22:59:36 CET Stephen Kelly wrote:
> On 02/15/2016 07:24 PM, Tobias Hunger wrote:
> > Hi Dominik,
> > 
> > Am 15.02.2016 19:01 schrieb "Dominik Haumann"  > 
> > >:
> > > 1. Wouldn't it make sense you have a developer sprint ASAP for this?
> > 
> > I'd be in, but I do not have the time to organize one. I could
> > probably get a room in our office though (in Berlin).
> 
> I'd be up for a sprint in Berlin too, but given the muted response so
> far here, it's not clear who would want to join and what we could achieve.

Considering the three of us (Tobias, you and me) are in Berlin, I'd say we at 
least meet for a hackday or so. What do you say? That would get me at least to 
work 8h on this for a full day and see how it integrates with KDevelop and we 
could discuss things in-person. Still, I'm aware that I'll have to play around 
with it before already to not waste too much of your time.

Bye
-- 
Milian Wolff
m...@milianw.de
http://milianw.de

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

Re: [cmake-developers] Bugfix for CPack / CPACK_INSTALL_CMAKE_PROJECTS

[Daniel Wirtz]

hey,

unfortunately i wont have the time to go dig in and provide a test for 
that .. my work on this project literally ends
in one week. we've got our own fork of cmake 
(https://github.com/OpenCMISS-Dependencies/CMake) that contains fix.


here's a patch (based on current master 
ed1b3430fcfc906780b68fe4a073590c6d23ff08) that at least gets this going.
i believe if no one yet complained about the missing feature, it may as 
well stay as "unsupported" as its been before - at least then the
current project group would not have to maintain an extra CMake fork and 
build process just for those two lines :-)


---

From 480a359e795d59d9176251f9d98dbadffafd9793 Mon Sep 17 00:00:00 2001
From: Daniel Wirtz 
Date: Thu, 18 Feb 2016 11:30:05 +1300
Subject: [PATCH]  Fixed the ignored SubDirectory directive for CPack using
 CPACK_INSTALL_CMAKE_PROJECTS

---
 Source/CPack/cmCPackGenerator.cxx | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Source/CPack/cmCPackGenerator.cxx 
b/Source/CPack/cmCPackGenerator.cxx

index 22d4bf0..3eca280 100644
--- a/Source/CPack/cmCPackGenerator.cxx
+++ b/Source/CPack/cmCPackGenerator.cxx
@@ -723,10 +723,9 @@ int 
cmCPackGenerator::InstallProjectViaInstallCMakeProjects(

 cmGlobalGenerator gg();
 cmsys::auto_ptr mf(
   new cmMakefile(, cm.GetCurrentSnapshot()));
-std::string realInstallDirectory = tempInstallDirectory;
 if ( !installSubDirectory.empty() && installSubDirectory != "/" )
   {
-  realInstallDirectory += installSubDirectory;
+  tempInstallDirectory += installSubDirectory;
   }
 if (componentInstall)
   {
--
2.7.0.windows.1


On 18.02.2016 04:56, Brad King wrote:

On 02/16/2016 03:46 PM, Daniel Wirtz wrote:

i think i've encountered a bug where the fourth (=SubDirectory) entry of
the CPACK_INSTALL_CMAKE_PROJECTS list is simply ignored.

[snip]

The offending lines of code have been committed in 2006 with
c09c3c6bfadb41bd0b43082642ce76abbf02df06 - i doubt that no one ever
tried to use something other than "/" since then?

That appears to be the case.  There is no test case in our test suite
for it either.  If you fix this please look at adding one.  Also update
the documentation to clarify the use case.

Thanks,
-Brad



--
Dr. Daniel Wirtz
Dipl. Math. Dipl. Inf.
SRC SimTech
Pfaffenwaldring 5a, D-70569 Stuttgart
+49 (711) 685-60044

--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake Daemon blog

[Stephen Kelly]

Taylor Braun-Jones wrote:

> On Sat, Jan 30, 2016 at 2:06 AM, Stephen Kelly
>  wrote:
>> I've just pushed the daemon code here:
>>
>>  https://github.com/steveire/cmake/tree/cmake-daemon
>>
>> The Kate plugin should soon appear here I think:
>>
>>  https://quickgit.kde.org/?p=scratch%2Fskelly%2Fcmakekate.git
> 
> Thanks for sharing, Stephen! Do you plan to also share the standalone
> Qt-based editor/client as well (cmake-browser)? That would be
> immediately useful to me and allow me to more easily test drive all
> this work that you've done.

I've deliberately not pushed that yet because it would put the wrong focus 
on the conversation:

* It doesn't need a test drive because I know it is limited by the daemon
* The focus needs to be on the implementation of the daemon first to make 
that work better. That can be done by anyone determined enough to paste some 
things into the stdin. 

For more see

 http://article.gmane.org/gmane.comp.programming.tools.cmake.devel/15740
 http://article.gmane.org/gmane.comp.programming.tools.cmake.devel/15741

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

[Stephen Kelly]

On 02/15/2016 07:24 PM, Tobias Hunger wrote:
>
> Hi Dominik,
>
> Am 15.02.2016 19:01 schrieb "Dominik Haumann"  >:
> > 1. Wouldn't it make sense you have a developer sprint ASAP for this?
>
> I'd be in, but I do not have the time to organize one. I could
> probably get a room in our office though (in Berlin).
>

I'd be up for a sprint in Berlin too, but given the muted response so
far here, it's not clear who would want to join and what we could achieve.

Thanks,

Steve.

-- 

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] Incorporating cmake dir into configure.ac, but it depends on a autconf-managed in-tree library

[Alexander Neundorf]

On Thursday, February 11, 2016 13:11:29 Ron wrote:
> Hi,
> 
> I am working on a project that requires libevent and libevhtp.
> The latter is cmake managed, my project and libevent are autoconf managed.
> 
> (Note that libevhtp depends on libevent, both depend on openssl, which I
> rely
> on the system to provide.)
> 
> The problem is that I run cmake during the configure step, but during that
> time libevent has not been built yet, so libevhtp complains about not
> finding
> the libevent library.
> 
> I have to use in-tree libevent and libevhtp due to features I need, and
> libevhtp
> not being distributed by the linux distro I use.
> 
> What is the best way to approach this?

you should have a look how libevhtp searches for libevent.
If it does a bunch of find_library()/find_path() calls, those set cmake cacge 
variables, but only if they are not set yet.
So if you know where libevent will put its stuff, you can preset those cmake 
cache variables (e.g. using cmake -D ...)

Alex

-- 

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] [PATCH]: CodeBlocks: improve support for different compilers

[Alexander Neundorf]

On Tuesday, February 16, 2016 10:49:24 Brad King wrote:
> On 02/12/2016 03:24 AM, melven.roehrig-zoell...@dlr.de wrote:
> > Just a small patch for the CodeBlocks generator
> 
> Thanks!  Applied:
> 
>  CodeBlocks: improve support for different compilers
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=184da3f4

Thanks :-)
Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] FindCUDA.cmake regression in 3.5.0-rc2

[Sorley, Stephen L.]

I tested your fix, it's working well for my project.  Thanks for the quick 
response!

-Stephen S.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: Wednesday, February 17, 2016 3:28 PM
To: Sorley, Stephen L.
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] FindCUDA.cmake regression in 3.5.0-rc2

On 02/17/2016 02:53 PM, Sorley, Stephen L. wrote:
> FindCUDA.cmake from 3.5.0-rc2 is failing for me when creating solution 
> files for Visual Studio on Windows (VS 2013 update 4, to be specific).  
> The ninja generator on Windows is unaffected.

Thanks for trying the release candidate and tracking this down!

In the long run I agree that switching away from $(VCInstallDir) is best, but 
it is mentioned in several other places within the module and is documented as 
a valid user-provided value.  For now I'd like to fix the regression with 
minimal changes.

Please test this fix on top of 3.5.0-rc2:

 FindCUDA: Fix regression under Visual Studio generators
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1911cda0

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] FindCUDA.cmake regression in 3.5.0-rc2

[Brad King]

On 02/17/2016 02:53 PM, Sorley, Stephen L. wrote:
> FindCUDA.cmake from 3.5.0-rc2 is failing for me when creating
> solution files for Visual Studio on Windows (VS 2013 update 4,
> to be specific).  The ninja generator on Windows is unaffected.

Thanks for trying the release candidate and tracking this down!

In the long run I agree that switching away from $(VCInstallDir)
is best, but it is mentioned in several other places within the
module and is documented as a valid user-provided value.  For
now I'd like to fix the regression with minimal changes.

Please test this fix on top of 3.5.0-rc2:

 FindCUDA: Fix regression under Visual Studio generators
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1911cda0

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, next, updated. v3.5.0-rc2-190-ge0bc653

[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  e0bc653bebfe35761662ca2d8052c0a347c011f2 (commit)
   via  1911cda03efc71f97e610e0b593282c835f2d4f4 (commit)
  from  5f6fe805da87fc1d3b4b66d0e9917643b626dd15 (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=e0bc653bebfe35761662ca2d8052c0a347c011f2
commit e0bc653bebfe35761662ca2d8052c0a347c011f2
Merge: 5f6fe80 1911cda
Author: Brad King 
AuthorDate: Wed Feb 17 15:25:57 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 17 15:25:57 2016 -0500

Merge topic 'FindCUDA-verbatim' into next

1911cda0 FindCUDA: Fix regression under Visual Studio generators


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1911cda03efc71f97e610e0b593282c835f2d4f4
commit 1911cda03efc71f97e610e0b593282c835f2d4f4
Author: Brad King 
AuthorDate: Wed Feb 17 15:14:22 2016 -0500
Commit: Brad King 
CommitDate: Wed Feb 17 15:20:56 2016 -0500

FindCUDA: Fix regression under Visual Studio generators

Since commit v3.5.0-rc1~47^2 (FindCUDA: Support special characters in
path, 2016-01-15) our add_custom_command calls use VERBATIM so that
CMake will automatically quote special characters correctly.  However,
this breaks the special `$(VCInstallDir)` placeholder used with Visual
Studio generators.  Since we do not support preservation of such
placeholders with VERBATIM (see issue #15001) we must fall back to not
using VERBATIM when the placeholder is used.

A better fix would be to stop using `$(VCInstallDir)` and use the value
of `CMAKE_${CUDA_C_OR_CXX}_COMPILER` instead, but that will require
additional semantic and documentation changes.  For now simply fix the
regression with the above approach.

Reported-by: Stephen Sorley 

diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index 1674e2d..47c03f3 100644
--- a/Modules/FindCUDA.cmake
+++ b/Modules/FindCUDA.cmake
@@ -1456,6 +1456,11 @@ macro(CUDA_WRAP_SRCS cuda_target format generated_files)
 set(cuda_build_comment_string "Building NVCC (${cuda_build_type}) 
object ${generated_file_relative_path}")
   endif()
 
+  set(_verbatim VERBATIM)
+  if(ccbin_flags MATCHES "\\$\\(VCInstallDir\\)")
+set(_verbatim "")
+  endif()
+
   # Build the generated file and dependency file ##
   add_custom_command(
 OUTPUT ${generated_file}
@@ -1474,7 +1479,7 @@ macro(CUDA_WRAP_SRCS cuda_target format generated_files)
   -P "${custom_target_script}"
 WORKING_DIRECTORY "${cuda_compile_intermediate_directory}"
 COMMENT "${cuda_build_comment_string}"
-VERBATIM
+${_verbatim}
 )
 
   # Make sure the build system knows the file is generated.
@@ -1586,6 +1591,11 @@ function(CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS 
output_file cuda_target options
   set(do_obj_build_rule FALSE)
 endif()
 
+set(_verbatim VERBATIM)
+if(nvcc_flags MATCHES "\\$\\(VCInstallDir\\)")
+  set(_verbatim "")
+endif()
+
 if (do_obj_build_rule)
   add_custom_command(
 OUTPUT ${output_file}
@@ -1593,7 +1603,7 @@ function(CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS 
output_file cuda_target options
 COMMAND ${CUDA_NVCC_EXECUTABLE} ${nvcc_flags} -dlink ${object_files} 
-o ${output_file}
 ${flags}
 COMMENT "Building NVCC intermediate link file 
${output_file_relative_path}"
-VERBATIM
+${_verbatim}
 )
 else()
   get_filename_component(output_file_dir "${output_file}" DIRECTORY)
@@ -1603,7 +1613,7 @@ function(CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS 
output_file cuda_target options
 COMMAND ${CMAKE_COMMAND} -E echo "Building NVCC intermediate link file 
${output_file_relative_path}"
 COMMAND ${CMAKE_COMMAND} -E make_directory "${output_file_dir}"
 COMMAND ${CUDA_NVCC_EXECUTABLE} ${nvcc_flags} ${flags} -dlink 
${object_files} -o "${output_file}"
-VERBATIM
+${_verbatim}
 )
 endif()
  endif()

---

Summary of changes:
 Modules/FindCUDA.cmake |   16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)


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

[cmake-developers] FindCUDA.cmake regression in 3.5.0-rc2

[Sorley, Stephen L.]

FindCUDA.cmake from 3.5.0-rc2 is failing for me when creating solution files 
for Visual Studio on Windows (VS 2013 update 4, to be specific).  The ninja 
generator on Windows is unaffected.

When I attempt to build a cuda target, the compile step for each .cu file fails 
with the following message:

Building NVCC (Device) object 
utils/CMakeFiles/utils_cu.dir/Release/utils_cu_generated_cudaarray.cu.obj
3>  cudaarray.cu
3>
3>  '$' is not recognized as an internal or external command,
3>
3>  operable program or batch file.
3>
3>  CMake Error at utils_cu_generated_cudaarray.cu.obj.cmake:207 (message):
3>Error generating
3>
C:/Users/sorlesl1/Desktop/testproj/build/utils/CMakeFiles/utils_cu.dir//Release/utils_cu_generated_cudaarray.cu.obj

I've traced the problem to this 
commit,
 which added VERBATIM to the add_custom_command() call in CUDA_WRAP_SRCS.

Adding the VERBATIM flag changes how the escaped double-quotes in the 
ccbin_flags variable are interpreted:

Without verbatim, ${ccbin_flags} expands to the following in the generated VS 
project:
   -D "CCBIN:PATH=$(VCInstallDir)bin"

With verbatim, the double quotes are escaped in the generated project, causing 
the error:
   -D \"CCBIN:PATH=$(VCInstallDir)bin\"

If the escaped quotes are omitted entirely when ccbin_flags is set, the custom 
command still fails, this time due to VCInstallDir expanding at compile time to 
a path containing spaces.

According to bug 15001, there isn't 
any way in CMake to correctly quote Visual Studio placeholder variables that 
expand to values containing spaces - you'll always get either no quotes, or 
escaped quotes.  However, I was able to work around this problem by getting the 
compiler path directly from CMake instead of using the placeholder.  Please see 
the attached patch (it's based on master) - with this patch, compiling CUDA 
code with Visual Studio works again.

Thanks,
Stephen Sorley


0001-Fixed-Visual-Studio-CUDA-compile-failure.patch
Description: 0001-Fixed-Visual-Studio-CUDA-compile-failure.patch
-- 

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.5.0-rc2-188-g5f6fe80

[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  5f6fe805da87fc1d3b4b66d0e9917643b626dd15 (commit)
   via  87f44b7525ebc9761b32b98f0c9e1276431e6ec1 (commit)
  from  ba189140f63bfd9166356ff608f1c281b9c0a394 (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=5f6fe805da87fc1d3b4b66d0e9917643b626dd15
commit 5f6fe805da87fc1d3b4b66d0e9917643b626dd15
Merge: ba18914 87f44b7
Author: Brad King 
AuthorDate: Wed Feb 17 14:11:35 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 17 14:11:35 2016 -0500

Merge topic 'fix-static-private-non-target-depends' into next

87f44b75 Fix export of STATIC library PRIVATE non-target dependencies


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=87f44b7525ebc9761b32b98f0c9e1276431e6ec1
commit 87f44b7525ebc9761b32b98f0c9e1276431e6ec1
Author: Brad King 
AuthorDate: Wed Feb 17 13:34:15 2016 -0500
Commit: Brad King 
CommitDate: Wed Feb 17 14:01:11 2016 -0500

Fix export of STATIC library PRIVATE non-target dependencies

In commit v3.5.0-rc1~43^2 (Fix export of STATIC library PRIVATE
dependencies with CMP0022 NEW, 2016-01-15) we taught
target_link_libraries to generate `$` in
INTERFACE_LINK_LIBRARIES instead of `$` so that `dep` can
be recognized as a target name and updated during export.  However, this
approach does not work when `dep` is just a plain library name and not a
target because `$` requires the name of a reachable
target.

Since we do not know during target_link_libraries whether the name will
correspond to a reachable target or not, we cannot inject the
`$` expression.  Revert this change and solve the
original problem instead by teaching the export logic to recognize and
update target names directly in `$` expressions.

Reported-by: Ben Boeckel 

diff --git a/Source/cmExportFileGenerator.cxx b/Source/cmExportFileGenerator.cxx
index e8a2e6a..c005995 100644
--- a/Source/cmExportFileGenerator.cxx
+++ b/Source/cmExportFileGenerator.cxx
@@ -772,6 +772,27 @@ cmExportFileGenerator::ResolveTargetsInGeneratorExpression(
 lastPos = endPos;
 }
 
+  pos = 0;
+  lastPos = pos;
+  while (errorString.empty() &&
+ (pos = input.find("$", nameStartPos);
+if (endPos == input.npos)
+  {
+  errorString = "$ expression incomplete";
+  break;
+  }
+std::string libName = input.substr(nameStartPos, endPos - nameStartPos);
+if (cmGeneratorExpression::IsValidTargetName(libName) &&
+this->AddTargetNamespace(libName, target, missingTargets))
+  {
+  input.replace(nameStartPos, endPos - nameStartPos, libName);
+  }
+lastPos = nameStartPos + libName.size() + 1;
+}
+
   this->ReplaceInstallPrefix(input);
 
   if (!errorString.empty())
diff --git a/Source/cmTargetLinkLibrariesCommand.cxx 
b/Source/cmTargetLinkLibrariesCommand.cxx
index 5f3246a..435346a 100644
--- a/Source/cmTargetLinkLibrariesCommand.cxx
+++ b/Source/cmTargetLinkLibrariesCommand.cxx
@@ -432,11 +432,8 @@ cmTargetLinkLibrariesCommand::HandleLibrary(const 
std::string& lib,
 {
 std::string configLib = this->Target
  ->GetDebugGeneratorExpressions(lib, llt);
-if (cmGeneratorExpression::IsValidTargetName(configLib))
-  {
-  configLib = "$>";
-  }
-else if (cmGeneratorExpression::Find(configLib) != std::string::npos)
+if (cmGeneratorExpression::IsValidTargetName(lib)
+|| cmGeneratorExpression::Find(lib) != std::string::npos)
   {
   configLib = "$";
   }
diff --git a/Tests/RunCMake/target_link_libraries/RunCMakeTest.cmake 
b/Tests/RunCMake/target_link_libraries/RunCMakeTest.cmake
index 8307607..1466fbf 100644
--- a/Tests/RunCMake/target_link_libraries/RunCMakeTest.cmake
+++ b/Tests/RunCMake/target_link_libraries/RunCMakeTest.cmake
@@ -8,3 +8,5 @@ run_cmake(MixedSignature)
 run_cmake(Separate-PRIVATE-LINK_PRIVATE-uses)
 run_cmake(SubDirTarget)
 run_cmake(SharedDepNotTarget)
+run_cmake(StaticPrivateDepNotExported)
+run_cmake(StaticPrivateDepNotTarget)
diff --git 
a/Tests/RunCMake/target_link_libraries/StaticPrivateDepNotExported-result.txt 

Re: [cmake-developers] [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5

[James Crosby]

> On 17 Feb 2016, at 14:33, Brad King  wrote:
>
> One could look at adding hooks to the compiler id logic to add alternatives
> provided by the toolchain file.  Or, we could provide a way to set the 
> compiler
> id but not also skip other checks.  In the worst case such a company could 
> modify
> their CMake for use with such a toolchain.  I do not consider this a blocking
> issue for deprecating CMakeForceCompiler.

I think allowing the compiler id to be set might be enough – in the case that
the compiler is completely unknown, functionality is anyway going to be limited
to what the user implements/supports themselves.


> It is not just a check that linking works.  CMake actually encodes string
> literals in the compiled binary and parses it to extract them.  This allows
> us to extract information about the compiler target architecture and compiler
> capabilities.  OTOH we may not actually have to link to achieve this.
>
> Perhaps we could have a setting in a toolchain file like
>
>set(CMAKE_TRY_COMPILE_NO_LINK 1)
>
> that tells CMake to use add_library(STATIC) instead of add_executable()
> in its generated try_compile projects.  That would avoid linking through
> the toolchain.

OK this makes a lot more sense to me now (I should have looked at the code
first ;). It seems like the option to link a static library would have all the
benefits of getting information out of the compiler itself (instead of
duplicating it in toolchain files), without having to be able to produce a
linkable executable.


> Meanwhile I've de-deprecated the module for the 3.5 release:

Thanks, this will be useful breathing space!


James

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

-- 

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] compiler independent compiler flags

[Ruslan Baratov via CMake]

On 17-Feb-16 17:23, Nagy-Egri Máté Ferenc via CMake wrote:


Unfortunately, I cannot help you in this regard, though I am surprised 
how little attention this question gained. I too feel that CMake could 
do better both in this regard. While ABI detection is very well done, 
BUILD_TYPE seems to be the only compiler agnostic option available.



...

I do not know how to set warning levels for eg. in a compiler agnostic 
manner


Just for your information: 
http://stackoverflow.com/questions/2368811/how-to-set-warning-level-in-cmake/24379666#24379666


Ruslo
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake 0015978]: Visual Studio 2015 Update 2 CTP support

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15978 
== 
Reported By:Niclas Larsén
Assigned To:
== 
Project:CMake
Issue ID:   15978
Category:   CMake
Reproducibility:always
Severity:   feature
Priority:   high
Status: new
== 
Date Submitted: 2016-02-17 11:06 EST
Last Modified:  2016-02-17 11:06 EST
== 
Summary:Visual Studio 2015 Update 2 CTP support
Description: 
the latest visual studio preview isn't supported by cmake.

-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:43 (project):
  No CMAKE_C_COMPILER could be found.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-02-17 11:06 Niclas Larsén  New Issue
==

-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.5.0-rc2-186-gba18914

[Nils Gladitz]

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  ba189140f63bfd9166356ff608f1c281b9c0a394 (commit)
   via  4a99b1b57809fcf5eb4da235a858e9bee9c3abe5 (commit)
  from  06168be1c3824a0850bb76e0f397aa74a7f8a763 (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=ba189140f63bfd9166356ff608f1c281b9c0a394
commit ba189140f63bfd9166356ff608f1c281b9c0a394
Merge: 06168be 4a99b1b
Author: Nils Gladitz 
AuthorDate: Wed Feb 17 11:03:45 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 17 11:03:45 2016 -0500

Merge topic 'unix-timestamps' into next

4a99b1b5 CMake: Extend TIMESTAMP sub-commands with new unix time format 
specifier


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4a99b1b57809fcf5eb4da235a858e9bee9c3abe5
commit 4a99b1b57809fcf5eb4da235a858e9bee9c3abe5
Author: Jose-Luis Blanco-Claraco 
AuthorDate: Tue Feb 16 21:48:56 2016 +0100
Commit: Nils Gladitz 
CommitDate: Wed Feb 17 17:00:08 2016 +0100

CMake: Extend TIMESTAMP sub-commands with new unix time format specifier

The new %s format specifier is substituted by file()/string()
TIMESTAMP sub-commands with the number of seconds since
unix-epoch (1 January 1970 00:00:00 UTC).

Co-Authored-By: Nils Gladitz 

diff --git a/Help/command/string.rst b/Help/command/string.rst
index 0361c74..3f4050e 100644
--- a/Help/command/string.rst
+++ b/Help/command/string.rst
@@ -277,6 +277,7 @@ specifiers:
%jThe day of the current year (001-366).
%mThe month of the current year (01-12).
%MThe minute of the current hour (00-59).
+   %sSeconds since midnight (UTC) 1-Jan-1970 (UNIX time).
%SThe second of the current minute.
  60 represents a leap second. (00-60)
%UThe week number of the current year (00-53).
diff --git a/Help/release/dev/unix-timestamps.rst 
b/Help/release/dev/unix-timestamps.rst
new file mode 100644
index 000..cdb0e5b
--- /dev/null
+++ b/Help/release/dev/unix-timestamps.rst
@@ -0,0 +1,6 @@
+unix-timestamps
+---
+
+* The :command:`string(TIMESTAMP)` and :command:`file(TIMESTAMP)`
+  commands gained support for the ``%s`` placeholder.  This is
+  the number of seconds since the UNIX Epoch.
diff --git a/Source/cmTimestamp.cxx b/Source/cmTimestamp.cxx
index 6fd6ab7..2cb3a15 100644
--- a/Source/cmTimestamp.cxx
+++ b/Source/cmTimestamp.cxx
@@ -12,9 +12,11 @@
 #include "cmTimestamp.h"
 
 #include 
+#include 
 
 #include 
 #include 
+#include 
 
 //
 std::string cmTimestamp::CurrentTime(
@@ -44,7 +46,7 @@ std::string cmTimestamp::FileModificationTime(const char* 
path,
 
 //
 std::string cmTimestamp::CreateTimestampFromTimeT(time_t timeT,
-std::string formatString, bool utcFlag)
+  std::string formatString, bool utcFlag) const
 {
   if(formatString.empty())
 {
@@ -79,12 +81,12 @@ std::string cmTimestamp::CreateTimestampFromTimeT(time_t 
timeT,
   for(std::string::size_type i = 0; i < formatString.size(); ++i)
 {
 char c1 = formatString[i];
-char c2 = (i+1 < formatString.size()) ?
-  formatString[i+1] : static_cast(0);
+char c2 = (i + 1 < formatString.size()) ?
+  formatString[i + 1] : static_cast(0);
 
 if(c1 == '%' && c2 != 0)
   {
-  result += AddTimestampComponent(c2, timeStruct);
+  result += AddTimestampComponent(c2, timeStruct, timeT);
   ++i;
   }
 else
@@ -97,8 +99,42 @@ std::string cmTimestamp::CreateTimestampFromTimeT(time_t 
timeT,
 }
 
 //
+time_t cmTimestamp::CreateUtcTimeTFromTm(struct tm ) const
+{
+#if defined(_MSC_VER) && _MSC_VER >= 1400
+  return _mkgmtime();
+#else
+  // From Linux timegm() manpage.
+
+  const char * tz = cmSystemTools::GetEnv("TZ");
+
+  if (tz)
+{
+tz = strdup(tz);
+}
+
+  // The standard says that "TZ=" or "TZ=[UNRECOGNIZED_TZ]" means UTC.
+  // It seems that "TZ=" does NOT work, at least under Windows
+  // with neither MSVC nor MinGW, so let's use explicit "TZ=UTC"
+
+  cmSystemTools::PutEnv(std::string("TZ=UTC"));
+
+  tzset();
+
+  time_t result = mktime();
+
+  cmSystemTools::PutEnv(std::string("TZ=") +
+std::string(tz ? tz : ""));
+
+  tzset();
+
+  return result;
+#endif
+}
+

[Cmake-commits] CMake branch, next, updated. v3.5.0-rc2-184-g06168be

[Nils Gladitz]

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  06168be1c3824a0850bb76e0f397aa74a7f8a763 (commit)
   via  3d2cdb0670cd0b50594dfb53efaaf80487959ead (commit)
  from  a3e303bd63a4ac6c5ed6a2ef0863f677194ecef9 (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=06168be1c3824a0850bb76e0f397aa74a7f8a763
commit 06168be1c3824a0850bb76e0f397aa74a7f8a763
Merge: a3e303b 3d2cdb0
Author: Nils Gladitz 
AuthorDate: Wed Feb 17 10:59:54 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 17 10:59:54 2016 -0500

Merge topic 'unix-timestamps' into next

3d2cdb06 !fixup CMake: Fix copy error in cmTimestamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3d2cdb0670cd0b50594dfb53efaaf80487959ead
commit 3d2cdb0670cd0b50594dfb53efaaf80487959ead
Author: Nils Gladitz 
AuthorDate: Wed Feb 17 16:59:29 2016 +0100
Commit: Nils Gladitz 
CommitDate: Wed Feb 17 16:59:29 2016 +0100

!fixup CMake: Fix copy error in cmTimestamp

diff --git a/Source/cmTimestamp.cxx b/Source/cmTimestamp.cxx
index 2724e2d..2cb3a15 100644
--- a/Source/cmTimestamp.cxx
+++ b/Source/cmTimestamp.cxx
@@ -157,7 +157,7 @@ std::string cmTimestamp::AddTimestampComponent(
   {
   // Build a time_t for UNIX epoch and substract from the input "timeT":
   struct tm tmUnixEpoch;
-  memset(, 0, sizeof(tmUnixEpoch));
+  memset(, 0, sizeof(tmUnixEpoch));
   tmUnixEpoch.tm_mday = 1;
   tmUnixEpoch.tm_year = 1970-1900;
 

---

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


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

[Cmake-commits] CMake branch, next, updated. v3.5.0-rc2-180-g27dc919

[Nils Gladitz]

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  27dc919a85b74389fe8335b4ac6bba990c82c3a1 (commit)
   via  eb5f4ece7281a83775ae9dd409f23e77c67e4743 (commit)
  from  46678f7d22fd0249e478f4896703fddc3035137c (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=27dc919a85b74389fe8335b4ac6bba990c82c3a1
commit 27dc919a85b74389fe8335b4ac6bba990c82c3a1
Merge: 46678f7 eb5f4ec
Author: Nils Gladitz 
AuthorDate: Wed Feb 17 10:50:47 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 17 10:50:47 2016 -0500

Merge topic 'unix-timestamps' into next

eb5f4ece !fixup CMake: Work around compiler warnings; add release note


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eb5f4ece7281a83775ae9dd409f23e77c67e4743
commit eb5f4ece7281a83775ae9dd409f23e77c67e4743
Author: Nils Gladitz 
AuthorDate: Wed Feb 17 16:45:15 2016 +0100
Commit: Nils Gladitz 
CommitDate: Wed Feb 17 16:45:15 2016 +0100

!fixup CMake: Work around compiler warnings; add release note

diff --git a/Help/release/dev/unix-timestamps.rst 
b/Help/release/dev/unix-timestamps.rst
new file mode 100644
index 000..cdb0e5b
--- /dev/null
+++ b/Help/release/dev/unix-timestamps.rst
@@ -0,0 +1,6 @@
+unix-timestamps
+---
+
+* The :command:`string(TIMESTAMP)` and :command:`file(TIMESTAMP)`
+  commands gained support for the ``%s`` placeholder.  This is
+  the number of seconds since the UNIX Epoch.
diff --git a/Source/cmTimestamp.cxx b/Source/cmTimestamp.cxx
index 6e059db..2724e2d 100644
--- a/Source/cmTimestamp.cxx
+++ b/Source/cmTimestamp.cxx
@@ -57,7 +57,8 @@ std::string cmTimestamp::CreateTimestampFromTimeT(time_t 
timeT,
   }
 }
 
-  struct tm timeStruct = {0};
+  struct tm timeStruct;
+  memset(, 0, sizeof(timeStruct));
 
   struct tm* ptr = (struct tm*) 0;
   if(utcFlag)
@@ -155,12 +156,13 @@ std::string cmTimestamp::AddTimestampComponent(
 case 's': // Seconds since UNIX epoch (midnight 1-jan-1970)
   {
   // Build a time_t for UNIX epoch and substract from the input "timeT":
-  struct tm tm_unix_epoch = {0};
-  tm_unix_epoch.tm_mday = 1;
-  tm_unix_epoch.tm_year = 1970-1900;
+  struct tm tmUnixEpoch;
+  memset(, 0, sizeof(tmUnixEpoch));
+  tmUnixEpoch.tm_mday = 1;
+  tmUnixEpoch.tm_year = 1970-1900;
 
-  const time_t unix_epoch = this->CreateUtcTimeTFromTm(tm_unix_epoch);
-  if (unix_epoch == -1)
+  const time_t unixEpoch = this->CreateUtcTimeTFromTm(tmUnixEpoch);
+  if (unixEpoch == -1)
 {
 cmSystemTools::Error("Error generating UNIX epoch in "
   "STRING(TIMESTAMP ...). Please, file a bug report aginst CMake");
@@ -168,7 +170,7 @@ std::string cmTimestamp::AddTimestampComponent(
 }
 
   std::stringstream ss;
-  ss << static_cast(difftime(timeT, unix_epoch));
+  ss << static_cast(difftime(timeT, unixEpoch));
   return ss.str();
   }
 default:

---

Summary of changes:
 Help/release/dev/unix-timestamps.rst |6 ++
 Source/cmTimestamp.cxx   |   16 +---
 2 files changed, 15 insertions(+), 7 deletions(-)
 create mode 100644 Help/release/dev/unix-timestamps.rst


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

Re: [cmake-developers] Bugfix for CPack / CPACK_INSTALL_CMAKE_PROJECTS

[Brad King]

On 02/16/2016 03:46 PM, Daniel Wirtz wrote:
> i think i've encountered a bug where the fourth (=SubDirectory) entry of 
> the CPACK_INSTALL_CMAKE_PROJECTS list is simply ignored.
[snip]
> The offending lines of code have been committed in 2006 with 
> c09c3c6bfadb41bd0b43082642ce76abbf02df06 - i doubt that no one ever 
> tried to use something other than "/" since then?

That appears to be the case.  There is no test case in our test suite
for it either.  If you fix this please look at adding one.  Also update
the documentation to clarify the use case.

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.5.0-rc2-88-g0cd8633

[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  0cd86338e0ca8f7706945b20c41805529524a8d5 (commit)
   via  bb7a41ab9b0b6a5a2cee3f330a2e223392ee4a70 (commit)
  from  445a37fc51ca1e295f3779b83c28d9f27624e9f0 (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=0cd86338e0ca8f7706945b20c41805529524a8d5
commit 0cd86338e0ca8f7706945b20c41805529524a8d5
Merge: 445a37f bb7a41a
Author: Brad King 
AuthorDate: Wed Feb 17 10:25:28 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 17 10:25:28 2016 -0500

Merge topic 'FindProtobuf-version'

bb7a41ab FindProtobuf: check version


---

Summary of changes:
 Help/release/dev/FindProtobuf-version.rst |6 +++
 Modules/FindProtobuf.cmake|   59 -
 Tests/CMakeOnly/AllFindModules/CMakeLists.txt |1 +
 3 files changed, 64 insertions(+), 2 deletions(-)
 create mode 100644 Help/release/dev/FindProtobuf-version.rst


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.5.0-rc2-90-ged1b343

[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  ed1b3430fcfc906780b68fe4a073590c6d23ff08 (commit)
   via  bf643286d32b569d20e7b7431ecc8755443fe5c4 (commit)
  from  0cd86338e0ca8f7706945b20c41805529524a8d5 (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=ed1b3430fcfc906780b68fe4a073590c6d23ff08
commit ed1b3430fcfc906780b68fe4a073590c6d23ff08
Merge: 0cd8633 bf64328
Author: Brad King 
AuthorDate: Wed Feb 17 10:25:31 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 17 10:25:31 2016 -0500

Merge topic 'FindwxWidgets-msys2-paths'

bf643286 FindwxWidgets: Resolve Cygwin/MSYS paths to Windows paths


---

Summary of changes:
 Modules/FindwxWidgets.cmake |   30 ++
 1 file changed, 30 insertions(+)


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

[Cmake-commits] CMake branch, master, updated. v3.5.0-rc2-86-g445a37f

[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  445a37fc51ca1e295f3779b83c28d9f27624e9f0 (commit)
   via  184da3f4f6ab74d2024455f8684286b2dbaa6a6e (commit)
  from  4468e083f40c108d39c0d1799410eeb194d4215c (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=445a37fc51ca1e295f3779b83c28d9f27624e9f0
commit 445a37fc51ca1e295f3779b83c28d9f27624e9f0
Merge: 4468e08 184da3f
Author: Brad King 
AuthorDate: Wed Feb 17 10:25:26 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 17 10:25:26 2016 -0500

Merge topic 'CodeBlocks-more-compilers'

184da3f4 CodeBlocks: improve support for different compilers


---

Summary of changes:
 Source/cmExtraCodeBlocksGenerator.cxx |   61 +
 1 file changed, 55 insertions(+), 6 deletions(-)


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

[Cmake-commits] CMake branch, next, updated. v3.5.0-rc2-178-g46678f7

[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  46678f7d22fd0249e478f4896703fddc3035137c (commit)
   via  ed1b3430fcfc906780b68fe4a073590c6d23ff08 (commit)
   via  0cd86338e0ca8f7706945b20c41805529524a8d5 (commit)
   via  445a37fc51ca1e295f3779b83c28d9f27624e9f0 (commit)
   via  4468e083f40c108d39c0d1799410eeb194d4215c (commit)
  from  7ed1d19a74cd9febfff80bde3d98c1f5f6a260d5 (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=46678f7d22fd0249e478f4896703fddc3035137c
commit 46678f7d22fd0249e478f4896703fddc3035137c
Merge: 7ed1d19 ed1b343
Author: Brad King 
AuthorDate: Wed Feb 17 10:25:40 2016 -0500
Commit: Brad King 
CommitDate: Wed Feb 17 10:25:40 2016 -0500

Merge branch 'master' into next


---

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


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

Re: [cmake-developers] Pssible documentation error in install(TARGETS ) signature

[Brad King]

On 02/16/2016 05:42 PM, Daniel Wirtz wrote:
> if the order of the arguments matters: update documentation?

Thanks, updated:

 Help: Clarify install(TARGETS) INCLUDES DESTINATION option
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c978223c

-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, next, updated. v3.5.0-rc2-173-g7ed1d19

[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  7ed1d19a74cd9febfff80bde3d98c1f5f6a260d5 (commit)
   via  c978223c859ba4a09cd30876e5f1f646748785e0 (commit)
  from  bef0a59e9e6358bba3f678eec72469e2450f616e (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=7ed1d19a74cd9febfff80bde3d98c1f5f6a260d5
commit 7ed1d19a74cd9febfff80bde3d98c1f5f6a260d5
Merge: bef0a59 c978223
Author: Brad King 
AuthorDate: Wed Feb 17 10:18:00 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 17 10:18:00 2016 -0500

Merge topic 'doc-install-component-association' into next

c978223c Help: Clarify install(TARGETS) INCLUDES DESTINATION option


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c978223c859ba4a09cd30876e5f1f646748785e0
commit c978223c859ba4a09cd30876e5f1f646748785e0
Author: Brad King 
AuthorDate: Wed Feb 17 10:11:01 2016 -0500
Commit: Brad King 
CommitDate: Wed Feb 17 10:14:54 2016 -0500

Help: Clarify install(TARGETS) INCLUDES DESTINATION option

The option does not actually participate in argument groups like the
others because it does not actually install anything.  Fix the order
in the documentation accordingly.

Reported-by: Daniel Wirtz 

diff --git a/Help/command/install.rst b/Help/command/install.rst
index 189b51c..aaf12cc 100644
--- a/Help/command/install.rst
+++ b/Help/command/install.rst
@@ -76,13 +76,14 @@ Installing Targets
   [[ARCHIVE|LIBRARY|RUNTIME|FRAMEWORK|BUNDLE|
 PRIVATE_HEADER|PUBLIC_HEADER|RESOURCE]
[DESTINATION ]
-   [INCLUDES DESTINATION [ ...]]
[PERMISSIONS permissions...]
[CONFIGURATIONS [Debug|Release|...]]
[COMPONENT ]
[OPTIONAL] [EXCLUDE_FROM_ALL]
[NAMELINK_ONLY|NAMELINK_SKIP]
-  ] [...])
+  ] [...]
+  [INCLUDES DESTINATION [ ...]]
+  )
 
 The ``TARGETS`` form specifies rules for installing targets from a
 project.  There are five kinds of target files that may be installed:
@@ -102,11 +103,7 @@ change the type of target to which the subsequent 
properties apply.
 If none is given the installation properties apply to all target
 types.  If only one is given then only targets of that type will be
 installed (which can be used to install just a DLL or just an import
-library).  The ``INCLUDES DESTINATION`` specifies a list of directories
-which will be added to the :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES`
-target property of the  when exported by the
-:command:`install(EXPORT)` command.  If a relative path is
-specified, it is treated as relative to the ``$``.
+library).
 
 The ``PRIVATE_HEADER``, ``PUBLIC_HEADER``, and ``RESOURCE`` arguments
 cause subsequent properties to be applied to installing a ``FRAMEWORK``
@@ -136,6 +133,14 @@ option installs nothing.  See the :prop_tgt:`VERSION` and
 :prop_tgt:`SOVERSION` target properties for details on creating versioned
 shared libraries.
 
+The ``INCLUDES DESTINATION`` specifies a list of directories
+which will be added to the :prop_tgt:`INTERFACE_INCLUDE_DIRECTORIES`
+target property of the  when exported by the
+:command:`install(EXPORT)` command.  If a relative path is
+specified, it is treated as relative to the ``$``.
+This is independent of the rest of the argument groups and does
+not actually install anything.
+
 One or more groups of properties may be specified in a single call to
 the ``TARGETS`` form of this command.  A target may be installed more than
 once to different locations.  Consider hypothetical targets ``myExe``,

---

Summary of changes:
 Help/command/install.rst |   19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)


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

Re: [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5

[Brad King]

On 02/15/2016 12:47 PM, James Crosby wrote:
> Using a dummy link command to check that linking works seems to
> undermine the purpose of checking in the first place, which suggests
> that perhaps it should still be possible to skip the check?

For reference, this discussion has moved to the cmake-developer list:

 Toolchains and CMAKE_FORCE_C_COMPILER in 3.5
 https://cmake.org/pipermail/cmake-developers/2016-February/027818.html

-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

Re: [cmake-developers] [PATCH 2/2] FindwxWidgets.cmake: Resolve CygWin/MSYS paths to Windows paths

[Brad King]

On 02/16/2016 04:15 PM, Simon Richter wrote:
> Hm, only problem is patch attribution here -- I've written that these
> are from Wayne, and should be attributed to him (but submitting these
> with his name in the From: field obviously would not have worked).

IIRC if you commit with --author='...' then `git format-patch` adds info
to the message that records the author even when you send the email.

> Can this still be fixed?

Yes, the patch had only been merged to 'next' for testing.  Here is a
revised version which will become the one merged to 'master':

 FindwxWidgets: Resolve Cygwin/MSYS paths to Windows paths
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf643286

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5

[Brad King]

Moving discussion to cmake-developers.

On 02/15/2016 12:47 PM, James Crosby wrote:
> I'm worried that built-in compiler detection might not be possible across
> the variety of cross-compilers used. In some cases, for example, the
> existence of a particular compiler, or a modified version of it, might be
> a secret outside of the company using it.

One could look at adding hooks to the compiler id logic to add alternatives
provided by the toolchain file.  Or, we could provide a way to set the compiler
id but not also skip other checks.  In the worst case such a company could 
modify
their CMake for use with such a toolchain.  I do not consider this a blocking
issue for deprecating CMakeForceCompiler.

> Using a dummy link command to check that linking works seems to
> undermine the purpose of checking in the first place, which suggests
> that perhaps it should still be possible to skip the check?

It is not just a check that linking works.  CMake actually encodes string
literals in the compiled binary and parses it to extract them.  This allows
us to extract information about the compiler target architecture and compiler
capabilities.  OTOH we may not actually have to link to achieve this.

Perhaps we could have a setting in a toolchain file like

set(CMAKE_TRY_COMPILE_NO_LINK 1)

that tells CMake to use add_library(STATIC) instead of add_executable()
in its generated try_compile projects.  That would avoid linking through
the toolchain.

Meanwhile I've de-deprecated the module for the 3.5 release:

 CMakeForceCompiler: De-deprecate until more use cases have alternatives
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=beaa4fa5

However, I'd really like to get a solution to the above worked out so
that it can be re-deprecated for the 3.6 release.  The module is simply
not compatible with all the information CMake now wants to detect from
toolchains.

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, next, updated. v3.5.0-rc2-171-gbef0a59

[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  bef0a59e9e6358bba3f678eec72469e2450f616e (commit)
   via  beaa4fa5ddba4298dfc94b38e1695bac28ea5faf (commit)
  from  02e0f707a9b63eba1219563afb253e0bd91353bb (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=bef0a59e9e6358bba3f678eec72469e2450f616e
commit bef0a59e9e6358bba3f678eec72469e2450f616e
Merge: 02e0f70 beaa4fa
Author: Brad King 
AuthorDate: Wed Feb 17 09:22:40 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 17 09:22:40 2016 -0500

Merge topic 'de-deprecate-CMakeForceCompiler' into next

beaa4fa5 CMakeForceCompiler: De-deprecate until more use cases have 
alternatives


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=beaa4fa5ddba4298dfc94b38e1695bac28ea5faf
commit beaa4fa5ddba4298dfc94b38e1695bac28ea5faf
Author: Brad King 
AuthorDate: Wed Feb 17 09:14:20 2016 -0500
Commit: Brad King 
CommitDate: Wed Feb 17 09:15:18 2016 -0500

CMakeForceCompiler: De-deprecate until more use cases have alternatives

We deprecated this module in commit v3.5.0-rc1~295^2
(CMakeForceCompiler: Deprecate this module and its macros, 2015-10-19)
in order to determine whether anyone still has use cases that require
it.  Indeed we still need to provide a way to work with toolchains that
cannot link binaries without special flags.  Remove the deprecation
warnings until we can provide an alternative to the module for this use
case.

diff --git a/Help/release/3.5.rst b/Help/release/3.5.rst
index 62703b3..009eb3c 100644
--- a/Help/release/3.5.rst
+++ b/Help/release/3.5.rst
@@ -159,9 +159,6 @@ Other
 Deprecated and Removed Features
 ===
 
-* The :module:`CMakeForceCompiler` module and its macros are now deprecated.
-  See module documentation for an explanation.
-
 * The :manual:`cmake(1)` ``-E time`` command now properly passes arguments
   with spaces or special characters through to the child process.  This
   may break scripts that worked around the bug with their own extra
diff --git a/Modules/CMakeForceCompiler.cmake b/Modules/CMakeForceCompiler.cmake
index 343ab3f..faa0dc5 100644
--- a/Modules/CMakeForceCompiler.cmake
+++ b/Modules/CMakeForceCompiler.cmake
@@ -2,7 +2,9 @@
 # CMakeForceCompiler
 # --
 #
-# Deprecated.  Do not use.
+# Discouraged.  Avoid using this module if possible.  It will be deprecated
+# by a future version of CMake once alternatives have been provided for all
+# toolchain file use cases.
 #
 # The macros provided by this module were once intended for use by
 # cross-compiling toolchain files when CMake was not able to automatically
@@ -12,6 +14,12 @@
 # CMake detects from a compiler is now too extensive to be provided by
 # toolchain files using these macros.
 #
+# The only known remaining use case for these macros is to write toolchain
+# files for cross-compilers that cannot link binaries without special flags or
+# custom linker scripts.  These macros cause CMake to skip checks it normally
+# performs as part of enabling a language and introspecting the toolchain.
+# However, skipping these checks may limit some generation functionality.
+#
 # -
 #
 # Macro CMAKE_FORCE_C_COMPILER has the following signature:
@@ -70,8 +78,6 @@
 #  License text for the above reference.)
 
 macro(CMAKE_FORCE_C_COMPILER compiler id)
-  message(DEPRECATION "The CMAKE_FORCE_C_COMPILER macro is deprecated.  "
-"Instead just set CMAKE_C_COMPILER and allow CMake to identify the 
compiler.")
   set(CMAKE_C_COMPILER "${compiler}")
   set(CMAKE_C_COMPILER_ID_RUN TRUE)
   set(CMAKE_C_COMPILER_ID ${id})
@@ -84,8 +90,6 @@ macro(CMAKE_FORCE_C_COMPILER compiler id)
 endmacro()
 
 macro(CMAKE_FORCE_CXX_COMPILER compiler id)
-  message(DEPRECATION "The CMAKE_FORCE_CXX_COMPILER macro is deprecated.  "
-"Instead just set CMAKE_CXX_COMPILER and allow CMake to identify the 
compiler.")
   set(CMAKE_CXX_COMPILER "${compiler}")
   set(CMAKE_CXX_COMPILER_ID_RUN TRUE)
   set(CMAKE_CXX_COMPILER_ID ${id})
@@ -98,8 +102,6 @@ macro(CMAKE_FORCE_CXX_COMPILER compiler id)
 endmacro()
 
 macro(CMAKE_FORCE_Fortran_COMPILER compiler id)
-  message(DEPRECATION "The CMAKE_FORCE_Fortran_COMPILER macro is deprecated.  "
-"Instead just set CMAKE_Fortran_COMPILER and allow CMake to identify the 
compiler.")
   set(CMAKE_Fortran_COMPILER "${compiler}")
   set(CMAKE_Fortran_COMPILER_ID_RUN TRUE)
   

[Cmake-commits] CMake branch, next, updated. v3.5.0-rc2-169-g02e0f70

[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  02e0f707a9b63eba1219563afb253e0bd91353bb (commit)
   via  8f153e9b9157236a14bc6a289453d6d4934ea048 (commit)
  from  fd8d38038c72efac13f7fbf040669697890c3a94 (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=02e0f707a9b63eba1219563afb253e0bd91353bb
commit 02e0f707a9b63eba1219563afb253e0bd91353bb
Merge: fd8d380 8f153e9
Author: Brad King 
AuthorDate: Wed Feb 17 09:05:01 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 17 09:05:01 2016 -0500

Merge topic 'reduce-entropy-consumption' into next

8f153e9b cmSystemTools: Avoid excess entropy consumption by RandomSeed 
(#15976)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8f153e9b9157236a14bc6a289453d6d4934ea048
commit 8f153e9b9157236a14bc6a289453d6d4934ea048
Author: Cristian Rodríguez 
AuthorDate: Wed Feb 17 09:02:04 2016 -0500
Commit: Brad King 
CommitDate: Wed Feb 17 09:04:44 2016 -0500

cmSystemTools: Avoid excess entropy consumption by RandomSeed (#15976)

Read `/dev/urandom` without buffering to avoid taking more than we need.

diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index 3ba7287..5ad2475 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -2184,8 +2184,10 @@ unsigned int cmSystemTools::RandomSeed()
   } seed;
 
   // Try using a real random source.
-  cmsys::ifstream fin("/dev/urandom");
-  if(fin && fin.read(seed.bytes, sizeof(seed)) &&
+  cmsys::ifstream fin;
+  fin.rdbuf()->pubsetbuf(0, 0); // Unbuffered read.
+  fin.open("/dev/urandom");
+  if(fin.good() && fin.read(seed.bytes, sizeof(seed)) &&
  fin.gcount() == sizeof(seed))
 {
 return seed.integer;

---

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


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

[Cmake-commits] CMake branch, next, updated. v3.5.0-rc2-167-gfd8d380

[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  fd8d38038c72efac13f7fbf040669697890c3a94 (commit)
   via  bf643286d32b569d20e7b7431ecc8755443fe5c4 (commit)
  from  99ae7c1b7e2338a18f054c927cbc64ed4b25e1a1 (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=fd8d38038c72efac13f7fbf040669697890c3a94
commit fd8d38038c72efac13f7fbf040669697890c3a94
Merge: 99ae7c1 bf64328
Author: Brad King 
AuthorDate: Wed Feb 17 08:53:48 2016 -0500
Commit: CMake Topic Stage 
CommitDate: Wed Feb 17 08:53:48 2016 -0500

Merge topic 'FindwxWidgets-msys2-paths' into next

bf643286 FindwxWidgets: Resolve Cygwin/MSYS paths to Windows paths


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf643286d32b569d20e7b7431ecc8755443fe5c4
commit bf643286d32b569d20e7b7431ecc8755443fe5c4
Author: Wayne Stambaugh 
AuthorDate: Sun Feb 14 20:51:11 2016 +0100
Commit: Brad King 
CommitDate: Wed Feb 17 08:52:56 2016 -0500

FindwxWidgets: Resolve Cygwin/MSYS paths to Windows paths

We use `sh wx-config` to launch the `wx-config` tool so that it can run
even on Windows.  Since it is always a shell script its output may use
POSIX paths even on Windows.  Use `cygpath` to convert to Windows paths.

diff --git a/Modules/FindwxWidgets.cmake b/Modules/FindwxWidgets.cmake
index 49ce57e..8c07e6c 100644
--- a/Modules/FindwxWidgets.cmake
+++ b/Modules/FindwxWidgets.cmake
@@ -835,6 +835,36 @@ else()
   endif()
 endif()
 
+# When using wx-config in MSYS, the include paths are UNIX style paths 
which may or may
+# not work correctly depending on you MSYS/MinGW configuration.  CMake 
expects native
+# paths internally.
+if(wxWidgets_FOUND AND MSYS)
+  find_program(_cygpath_exe cygpath ONLY_CMAKE_FIND_ROOT_PATH)
+  DBG_MSG_V("_cygpath_exe:  ${_cygpath_exe}")
+  if(_cygpath_exe)
+set(_tmp_path "")
+foreach(_path ${wxWidgets_INCLUDE_DIRS})
+  execute_process(
+COMMAND cygpath -w ${_path}
+OUTPUT_VARIABLE _native_path
+RESULT_VARIABLE _retv
+OUTPUT_STRIP_TRAILING_WHITESPACE
+ERROR_QUIET
+)
+  if(_retv EQUAL 0)
+file(TO_CMAKE_PATH ${_native_path} _native_path)
+DBG_MSG_V("Path ${_path} converted to ${_native_path}")
+set(_tmp_path "${_tmp_path} ${_native_path}")
+  endif()
+endforeach()
+DBG_MSG("Setting wxWidgets_INCLUDE_DIRS = ${_tmp_path}")
+set(wxWidgets_INCLUDE_DIRS ${_tmp_path})
+separate_arguments(wxWidgets_INCLUDE_DIRS)
+list(REMOVE_ITEM wxWidgets_INCLUDE_DIRS "")
+  endif()
+  unset(_cygpath_exe CACHE)
+endif()
+
 #=
 # Neither UNIX_FIND_STYLE, nor WIN32_FIND_STYLE
 #=

---

Summary of changes:


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

Re: [CMake] compiler independent compiler flags

[ Jan Hegewald]

> On 17.02.2016, at 11:23, Nagy-Egri Máté Ferenc via CMake  
> wrote:
> 
> Sorry I could not help, but I do feel the struggle.

LOL, yes. Struggle might be the right term.

Best,
Jan
-- 

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] compiler wrappers and linking libraries

[ Jan Hegewald]

Dear all,
on a system with a cray compiler environment cmake fails to find a blas capable 
library via

find_package(BLAS) 

The compilers on this system are wrappers which already link the local blas 
libraries (from the cray-libsci library). I guess this is why a call to

check_fortran_function_exists(sgemm HAS_BLAS)
or
check_function_exists(cblas_sgemm HAS_BLAS)

actually succeeds. (sgemm is a symbol from BLAS)

So the code requires blas functionality, but I can not just call 
find_package(BLAS) and then add the BLAS_LIBRARIES to the targets linker flags 
as on other platforms.
Do you think we should refine the FindBLAS.cmake to actually detect if blas is 
already be found by the compiler/linker and then set BLAS_FOUND to true and 
BLAS_LIBRARIES to an empty list?

Thanks for any thoughts about this,
Jan 
-- 

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] compiler independent compiler flags

[Petr Kmoch]

Hi.

There is certainly room for providing more, but BUILD_TYPE is not the only
option settable in a compiler-agnostic way. There are target properties:

C_STANDARD
CXX_STANDARD
INCLUDE_DIRECTORIES
INTERPROCEDURAL_OPTIMIZATION
POSITION_INDEPENDENT_CODE
WIN32_EXECUTABLE

and maybe more (I do not claim the list above to be exhaustive).

Petr

On Wed, Feb 17, 2016 at 11:23 AM, Nagy-Egri Máté Ferenc 
wrote:

> Hi Jan,
>
>
>
> Unfortunately, I cannot help you in this regard, though I am surprised how
> little attention this question gained. I too feel that CMake could do
> better both in this regard. While ABI detection is very well done,
> BUILD_TYPE seems to be the only compiler agnostic option available. I do
> not know how to set warning levels for eg. in a compiler agnostic manner.
> Aside from this, there are dozens of other options that are common to all
> C++ compilers and it would rock if I need not look up the exact params for
> all of them.
>
>
>
> Sorry I could not help, but I do feel the struggle.
>
>
>
> Cheers,
>
> Máté
>
>
>
> *Feladó: * Jan Hegewald 
> *Elküldve: *2016. február 5., péntek 11:36
> *Címzett: *cmake@cmake.org
> *Tárgy: *[CMake] compiler independent compiler flags
>
>
>
> Dear all,
>
> do you know a best practice on how to specify compiler flags without
> knowing in advance which compiler will be used?
>
> Its about Fortran projects, where I e.g. want to explicitly enable the
> preprocessor, or make all default real values 8 byte wide. This could be
> done as such:
>
> if(${CMAKE_Fortran_COMPILER_ID} STREQUAL "Intel")
>
>   set(CMAKE_Fortran_FLAGS "-fpp -r8")
>
> elseif(${CMAKE_Fortran_COMPILER_ID} STREQUAL "GNU")
>
>   set(CMAKE_Fortran_FLAGS "-cpp -fdefault-real-8")
>
> endif()
>
>
>
> Cmake has the cmake-compile-features and I though maybe some similar
> mechanism exists for above mentioned compiler switches. So I could say
>
> target_compile_features(mylib PRIVATE f_preprocessor f_real_8)
>
>
>
> Thanks for sharing your advise,
>
> Jan
>
>
>
>
>
> --
>
>
>
> 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
>
-- 

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] compiler independent compiler flags

[Nagy-Egri Máté Ferenc via CMake]

Hi Jan,

Unfortunately, I cannot help you in this regard, though I am surprised how 
little attention this question gained. I too feel that CMake could do better 
both in this regard. While ABI detection is very well done, BUILD_TYPE seems to 
be the only compiler agnostic option available. I do not know how to set 
warning levels for eg. in a compiler agnostic manner. Aside from this, there 
are dozens of other options that are common to all C++ compilers and it would 
rock if I need not look up the exact params for all of them.

Sorry I could not help, but I do feel the struggle.

Cheers,
Máté

Feladó:  Jan Hegewald
Elküldve: 2016. február 5., péntek 11:36
Címzett: cmake@cmake.org
Tárgy: [CMake] compiler independent compiler flags

Dear all,
do you know a best practice on how to specify compiler flags without knowing in 
advance which compiler will be used?
Its about Fortran projects, where I e.g. want to explicitly enable the 
preprocessor, or make all default real values 8 byte wide. This could be done 
as such:
if(${CMAKE_Fortran_COMPILER_ID} STREQUAL "Intel")
  set(CMAKE_Fortran_FLAGS "-fpp -r8")
elseif(${CMAKE_Fortran_COMPILER_ID} STREQUAL "GNU")
  set(CMAKE_Fortran_FLAGS "-cpp -fdefault-real-8")
endif()

Cmake has the cmake-compile-features and I though maybe some similar mechanism 
exists for above mentioned compiler switches. So I could say
target_compile_features(mylib PRIVATE f_preprocessor f_real_8)

Thanks for sharing your advise,
Jan


-- 

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] Run program/command before test

[Roman Wüger]

Hi Nils,

great thanks.

Regards
Roman 

> Am 17.02.2016 um 09:09 schrieb Nils Gladitz :
> 
>> On 17.02.2016 07:58, Roman Wüger wrote:
>> Ok thanks
>> 
>> Would it be an opinion to have a COMMAND parameter for the add_test function 
>> like execute_process where every COMMAND must return the exit code and this 
>> would be ored?
>> 
>> add_test(MyTest COMMAND myserver --port 80
>>   COMMAND mytest
>>   COMMAND myserver --graceful-shutdown)
>> 
>> Or
>> 
>> add_test(MyTest PRE_COMMAND myserver --port 80
>>   COMMAND mytest
>>   POST_COMMAND myserver --graceful-shutdown)
> 
> What you could already do is wrap your test in a cmake script.
> 
> E.g.
> 
>add_test(NAME MyTest
>COMMAND ${CMAKE_COMMAND} -DACTUAL_TEST=$ -P 
> ${CMAKE_CURRENT_SOURCE_DIR}/mywrapper.cmake
>)
> 
> Where mywrapper.cmake could do something like:
> 
>execute_process(COMMAND mysever --port 80 ...)
> 
>execute_process(COMMAND ${ACTUAL_TEST} )
> 
>execute_process(COMMAND mysever --graceful-shutdown)
> 
> To have the test fail you could call message(FATAL_ERROR "...")
> 
> For this to work myserver would have to daemonize/fork (but I assume that is 
> the case given your example).
> 
> 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-developers

Re: [cmake-developers] Run program/command before test

[Nils Gladitz]

On 17.02.2016 07:58, Roman Wüger wrote:

Ok thanks

Would it be an opinion to have a COMMAND parameter for the add_test function 
like execute_process where every COMMAND must return the exit code and this 
would be ored?

add_test(MyTest COMMAND myserver --port 80
   COMMAND mytest
   COMMAND myserver --graceful-shutdown)

Or

add_test(MyTest PRE_COMMAND myserver --port 80
   COMMAND mytest
   POST_COMMAND myserver --graceful-shutdown)


What you could already do is wrap your test in a cmake script.

E.g.

add_test(NAME MyTest
COMMAND ${CMAKE_COMMAND} -DACTUAL_TEST=$ -P 
${CMAKE_CURRENT_SOURCE_DIR}/mywrapper.cmake

)

Where mywrapper.cmake could do something like:

execute_process(COMMAND mysever --port 80 ...)

execute_process(COMMAND ${ACTUAL_TEST} )

execute_process(COMMAND mysever --graceful-shutdown)

To have the test fail you could call message(FATAL_ERROR "...")

For this to work myserver would have to daemonize/fork (but I assume 
that is the case given your example).


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