[cmake-developers] [CMake 0015086]: CUDA_ADD_EXECUTABLE generates invalid VS2012 projects when source .cu file is a relative path beggining with ../
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15086 == Reported By:Ignasi Rius Assigned To: == Project:CMake Issue ID: 15086 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2014-08-14 06:22 EDT Last Modified: 2014-08-14 06:22 EDT == Summary:CUDA_ADD_EXECUTABLE generates invalid VS2012 projects when source .cu file is a relative path beggining with ../ Description: An invalid Visual Studio 2012 project is generated when CUDA_ADD_EXECUTABLE is called with a source file such as: cuda_add_executable(testFindCuda ../3rdparty/testCuda.cu) VS complaints that the .cu file is included in both the CustomBuild and None ItemGroups and the project simply doesn't load. However, if the testCuda.cu file is specified with an absolut path everything works fine. Steps to Reproduce: I have included a toy example to reproduce the problem (check testFindCuda.rar). 1) Just extract the files, and run cmake-gui (Windows) on testFindCuda/mainProject. 2) Generate a Visual Studio 11 2012 solution. 3) Open the resulting .sln with VS2012 and you'll see that it's broken. Additional Information: In particular it seems that the offending line in the .vcxproj file is: None Include=C:\Temp\testFindCuda\3rdparty\testCuda.cu / == Issue History Date ModifiedUsername FieldChange == 2014-08-14 06:22 Ignasi RiusNew Issue 2014-08-14 06:22 Ignasi RiusFile Added: testFindCuda.rar == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015087]: Bug in FindwxWidgets.cmake causes build failure when more than one C flag is used.
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15087
==
Reported By:hobbes1069
Assigned To:
==
Project:CMake
Issue ID: 15087
Category: Modules
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2014-08-14 16:17 EDT
Last Modified: 2014-08-14 16:17 EDT
==
Summary:Bug in FindwxWidgets.cmake causes build failure when
more than one C flag is used.
Description:
FindwxWidgets.cmake parses the output of wx-config and converts it to a list.
The definitions and includes seem to be processed appropriately but whatever is
left is considered a CXX flag.
If more than one flag remains it is left as a cmake list, i.e.:
-mthreads;-fpermissive which gcc chokes on.
On both my Fedora and Fedora mingw-w64 installs only one flag is used and the
issue doesn't crop up.
Steps to Reproduce:
Attempt to build a cmake based project that uses wxWidgets with more than one
build flag.
Additional Information:
The following patch worked for me but should be reviewed for appropriateness:
diff -Naur cmake-3.0.1.orig/Modules/FindwxWidgets.cmake
cmake-3.0.1.wxfix/Modules/FindwxWidgets.cmake
--- cmake-3.0.1.orig/Modules/FindwxWidgets.cmake2014-07-31
10:03:56.0 -0500
+++ cmake-3.0.1.wxfix/Modules/FindwxWidgets.cmake 2014-08-14
12:02:11.604331400 -0500
@@ -792,6 +792,10 @@
wxWidgets_CXX_FLAGS ${wxWidgets_CXX_FLAGS})
string(REPLACE -I
wxWidgets_INCLUDE_DIRS ${wxWidgets_INCLUDE_DIRS})
+
+ # Flags are a string, not a list, fix it here
+ string(REPLACE ;
+ wxWidgets_CXX_FLAGS ${wxWidgets_CXX_FLAGS})
DBG_MSG_V(wxWidgets_DEFINITIONS=${wxWidgets_DEFINITIONS})
DBG_MSG_V(wxWidgets_INCLUDE_DIRS=${wxWidgets_INCLUDE_DIRS})
==
Issue History
Date ModifiedUsername FieldChange
==
2014-08-14 16:17 hobbes1069 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-developers] [CMake 0015088]: Ninja generator makes an invalid RC_COMPILER rule
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15088
==
Reported By:Frank Miller
Assigned To:
==
Project:CMake
Issue ID: 15088
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2014-08-14 17:45 EDT
Last Modified: 2014-08-14 17:45 EDT
==
Summary:Ninja generator makes an invalid RC_COMPILER rule
Description:
When the project() command is used without C language support as in
project(myproj CXX), the ninja generator will create a rules.ninja file with an
empty string where cmcldeps.exe should be. Something like the following:
rule RC_COMPILER
depfile = $DEP_FILE
deps = gcc
command = RC $in $DEP_FILE $out Note: including file: c:/Program
Files (x86)/Microsoft Visual Studio 12.0/VC/bin/cl.exe
c:\PROGRA~2\WI3CF2~1\8.1\bin\x86\rc.exe $FLAGS $DEFINES /fo$out $in
description = Building RC object $out
Steps to Reproduce:
The following patch will cause the MFC test to fail
diff --git a/Tests/MFC/CMakeLists.txt.in b/Tests/MFC/CMakeLists.txt.in
index e6bfabd..c1d0754 100644
--- a/Tests/MFC/CMakeLists.txt.in
+++ b/Tests/MFC/CMakeLists.txt.in
@@ -1,5 +1,5 @@
cmake_minimum_required(VERSION 2.8)
-project(mfc1)
+project(mfc1 CXX)
macro(replace_flags var these those)
if(${${var}} MATCHES ${these})
Additional Information:
This used to work in cmake 2.8.
==
Issue History
Date ModifiedUsername FieldChange
==
2014-08-14 17:45 Frank Miller 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-developers] New platform file for Cray Compute Node Linux
I've been using CMake on Cray's quite a bit lately and some of the cross
compilation leaves a bit to be desired. No particular capability is really
missing but the foo of getting things to build and work seems to be
rather dispersed across various individuals and corners of the internet.
I'd like to start pooling some of this together to be shipped with CMake.
For starters, I'd like to add a Platform file for the cross compilation
target of ComputeNodeLinux. While it's not entirely different from running
Linux natively, some assumptions from native host Linux build environments
aren't valid and building for it explicitly needs search paths defined by
the Cray environment modules. It's also distinctly different from the
commonly used Catamount (which is very far removed from the currently used
OS). Attached is a patch for a new Platform file that uses information from
the loaded environment modules on the login nodes to define it's
appropriate path and version info. I've been using this successfully on
Garnet (an XE6) and Titan (an XK7).
- Chuck
From 980483bbc2e0040273f9c7fa8df3c6bf61bba311 Mon Sep 17 00:00:00 2001
From: Chuck Atkins chuck.atk...@kitware.com
Date: Thu, 14 Aug 2014 18:30:01 -0400
Subject: [PATCH] Add a platform file for cross-compiling to Cray Compute Node
Linux
This platform module is designed t be used with the Cray Programming
Environment. Esentially this means that it will get it's various
options and settings through variables loaded in environment modules
used on modern Crays.
---
Modules/Platform/ComputeNodeLinux.cmake | 33 +
1 file changed, 33 insertions(+)
create mode 100644 Modules/Platform/ComputeNodeLinux.cmake
diff --git a/Modules/Platform/ComputeNodeLinux.cmake b/Modules/Platform/ComputeNodeLinux.cmake
new file mode 100644
index 000..58fbcd5
--- /dev/null
+++ b/Modules/Platform/ComputeNodeLinux.cmake
@@ -0,0 +1,33 @@
+# Compute Node Linux doesn't quite work the same as native Linux so all of this
+# needs to be custom. We use the variables defined through Cray's environment
+# modules to set up the right paths for things.
+
+if(NOT CMAKE_SYSTEM_VERSION)
+ if(NOT DEFINED ENV{XTOS_VERSION})
+message(FATAL_ERROR The CMAKE_SYSTEM_VERSION variable is not set and the XTOS_VERSION environment variable is not defined. The ComputeNodeLinux CMake platform module either requires it to be manually set or the XTOS_VERSION environment variable to be available. This usually means that the necessary PrgEnv-* module is not loaded)
+ else()
+set(CMAKE_SYSTEM_VERSION $ENV{XTOS_VERSION})
+ endif()
+endif()
+
+# Compute Node Linux does support shared libraries, it's just seldom used
+set_property(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS TRUE)
+set(CMAKE_SHARED_LIBRARY_PREFIX lib)
+set(CMAKE_SHARED_LIBRARY_SUFFIX .so)
+set(CMAKE_STATIC_LIBRARY_PREFIX lib)
+set(CMAKE_STATIC_LIBRARY_SUFFIX .a)
+
+# Make sure we have the appropriate environment loaded
+if(NOT DEFINED ENV{SYSROOT_DIR})
+ message(FATAL_ERROR The SYSROOT_DIR environment variable is not defined but the ComputeNodeLinux CMake platform module requires it. This usually means that the necessary PrgEnv-* module is not loaded)
+endif()
+
+# Set up system search paths that CMake will use to look for libraries and
+# include files. These will be the standard UNIX search paths but rooted
+# in the SYSROOT of the computes nodes.
+include(Platform/UnixPaths)
+set(CMAKE_FIND_ROOT_PATH $ENV{SYSROOT_DIR})
+set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
+set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
+set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
+set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
--
1.9.3
--
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] [PATCH] New module: FindIce.cmake
On Wed, Aug 13, 2014 at 10:10:01AM -0400, Brad King wrote:
On 08/12/2014 05:59 PM, Roger Leigh wrote:
Regarding the Windows Registry, I've taken a look and it looks
like there might be some usable keys from the installer which
could be used, but I'll need to do further digging with all
the different versions to see what's most usable here.
This turned out to be fairly simple at least for Ice versions
3.4.0 - 3.5.1, which all have the same naming convention.
Earlier versions have odd naming conventions and are in
Wow6432Node so I've not included them (they are obsolete in
any case, and ICE_HOME can be set to use them).
The Wow6432Node is for distinguishing between 32-bit and 64-bit
views of the registry. Just omit it from any registry key path.
When CMake find_* commands evaluate registry values they take
into account whether the target architecture is 32-bit or 64-bit
and prefer the matching registry view.
So, please go ahead and add the registry entries for the earlier
versions. Just convert any \Wow6432Node\ to \ in the keys.
OK, done now and it's working fine.
Other comments:
+# Components can include any of: Freeze Glacier2 Ice IceBox IceDB
+# IceGrid IcePatch IceSSL IceStorm IceUtil IceXML Slice.
I think each name in the list should be ``quoted`` to clarify
that it is a name to appear in code.
Done.
+# ICE_LIBRARIES - component libraries to be linked
Is that a typo in the docs? It should be Ice_LIBRARIES.
Yes, fixed now.
+# ICE_C_LIBRARY - component library
Although the individual find result is a singular-named cache entry
the results presented to the project should still be plural-named
normal variables:
Ice_C_LIBRARY - cache entry
Ice_C_LIBRARIES - results (even if only one entry)
This is also fixed.
+set(ICE_HOME NOTFOUND
+CACHE PATH Location of the Ice installation)
+mark_as_advanced(FORCE ICE_HOME)
+
+set(ICE_BINARYDIR NOTFOUND
+CACHE PATH Location of the Ice programs)
+mark_as_advanced(FORCE ICE_BINARYDIR)
+
+set(ICE_INCLUDEDIR NOTFOUND
+CACHE PATH Location of the Ice headers)
+mark_as_advanced(FORCE ICE_INCLUDEDIR)
+
+set(ICE_SLICEDIR NOTFOUND
+CACHE PATH Location of the Ice slice interface definitions)
+mark_as_advanced(FORCE ICE_SLICEDIR)
+
+set(ICE_LIBRARYDIR NOTFOUND
+CACHE PATH Location of the Ice libraries)
+mark_as_advanced(FORCE ICE_LIBRARYDIR)
These hints should not need to be explicitly cached with such
granularity. The find_* commands create cache entries for
their results both to save them persistently and to allow users
to set them granularly. The CMAKE_PREFIX_PATH variable allows
users to add custom prefixes without a per-package _HOME or
_ROOT variable.
These are all removed.
+ list(APPEND ice_slice_paths
+/usr/local/share/Ice-${Ice_VERSION_SLICE2CPP_FULL}/slice
+/usr/local/share/Ice-${Ice_VERSION_SLICE2CPP_SHORT}/slice
+/usr/local/share/Ice/slice
+/usr/share/Ice-${Ice_VERSION_SLICE2CPP_FULL}/slice
+/usr/share/Ice-${Ice_VERSION_SLICE2CPP_SHORT}/slice
+/usr/share/Ice/slice)
It looks like a lot of the explicit search location construction
could be simplified using PATH_SUFFIXES options to the find
commands. There should not need to be any explicit copies of
paths for every common prefix.
I have changed all the find_* code to use PATH_SUFFIXES and the
correct cache variable names. It certainly has simplified things
quite a bit.
Another option you might be interested in exploring, but not
as a requirement for our acceptance of this module, is creation
of imported targets to hold the find results with usage reqs.
See the cmake-buildsystem(7) manual:
http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html
for more info. See the FindQt4 module for an example. This
part could be added as a follow-up change once the main module
is in though.
OK. I'll have to read up on this and see what needs doing.
In the meantime, I've attached a revised patch with all the
above corrections included.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
From 0ee1f79f060579e036e9158020c1650df6759d67 Mon Sep 17 00:00:00 2001
From: Roger Leigh r.le...@dundee.ac.uk
Date: Thu, 7 Aug 2014 18:37:36 +0100
Subject: [PATCH] FindIce: New module to find ZeroC Ice
- autodetects Ice on all major platforms
- allows building with all supported Visual Studio versions on Windows
- autodetects the slice path on most platforms
- separately detects the Ice programs, headers, slice files and
libraries so that any Ice configuration or installation errors can
be accurately reported, making diagnosis of Ice problems simpler
---
Help/manual/cmake-modules.7.rst | 1 +
Help/module/FindIce.rst
Re: [cmake-developers] New platform file for Cray Compute Node Linux
Updated to allow for static and shared libs (yes, you can use shared libs
on a cray). The expectation is that your toolchain file will have the
appropriate logic to deal with this. Something like:
set(CMAKE_SYSTEM_NAME ComputeNodeLinux)
...
if(DEFINED ENV{CRAYPE_LINK_TYPE} AND
$ENV{CRAYPE_LINK_TYPE} EQUALS dynamic)
set(_CRAY_LINK_OPTS -dynamic)
else()
# The default behavior if not specified is explicit static-only linkage
set(_CRAY_LINK_OPTS -static)
# If we're using static linking then make sure that CMake explicitly
# only looks for static libraries
set(CMAKE_FIND_LIBRARY_SUFFIXES .a)
endif()
...
set(CMAKE_C_FLAGS ... ${_CRAY_LINK} CACHE STRING FORCE)
set(CMAKE_CXX_FLAGS ... ${_CRAY_LINK} CACHE STRING FORCE)
set(CMAKE_Fortran_FLAGS ... ${_CRAY_LINK} CACHE STRING FORCE)
- Chuck
On Thu, Aug 14, 2014 at 6:46 PM, Chuck Atkins chuck.atk...@kitware.com
wrote:
I've been using CMake on Cray's quite a bit lately and some of the cross
compilation leaves a bit to be desired. No particular capability is really
missing but the foo of getting things to build and work seems to be
rather dispersed across various individuals and corners of the internet.
I'd like to start pooling some of this together to be shipped with CMake.
For starters, I'd like to add a Platform file for the cross compilation
target of ComputeNodeLinux. While it's not entirely different from running
Linux natively, some assumptions from native host Linux build environments
aren't valid and building for it explicitly needs search paths defined by
the Cray environment modules. It's also distinctly different from the
commonly used Catamount (which is very far removed from the currently used
OS). Attached is a patch for a new Platform file that uses information from
the loaded environment modules on the login nodes to define it's
appropriate path and version info. I've been using this successfully on
Garnet (an XE6) and Titan (an XK7).
- Chuck
From f386ceb9f1f35c873ce34420bc5d143868c6e8d6 Mon Sep 17 00:00:00 2001
From: Chuck Atkins chuck.atk...@kitware.com
Date: Thu, 14 Aug 2014 18:30:01 -0400
Subject: [PATCH] Add a platform file for cross-compiling to Cray Compute Node
Linux
This platform module is designed t be used with the Cray Programming
Environment. Esentially this means that it will get it's various
options and settings through variables loaded in environment modules
used on modern Crays.
---
Modules/Platform/ComputeNodeLinux.cmake | 36 +
1 file changed, 36 insertions(+)
create mode 100644 Modules/Platform/ComputeNodeLinux.cmake
diff --git a/Modules/Platform/ComputeNodeLinux.cmake b/Modules/Platform/ComputeNodeLinux.cmake
new file mode 100644
index 000..ae6aa94
--- /dev/null
+++ b/Modules/Platform/ComputeNodeLinux.cmake
@@ -0,0 +1,36 @@
+# Compute Node Linux doesn't quite work the same as native Linux so all of this
+# needs to be custom. We use the variables defined through Cray's environment
+# modules to set up the right paths for things.
+
+if(NOT CMAKE_SYSTEM_VERSION)
+ if(NOT DEFINED ENV{XTOS_VERSION})
+message(FATAL_ERROR The CMAKE_SYSTEM_VERSION variable is not set and the XTOS_VERSION environment variable is not defined. The ComputeNodeLinux CMake platform module either requires it to be manually set or the XTOS_VERSION environment variable to be available. This usually means that the necessary PrgEnv-* module is not loaded)
+ else()
+set(CMAKE_SYSTEM_VERSION $ENV{XTOS_VERSION})
+ endif()
+endif()
+
+# Contrary to popular belief, you can use shared libraries on a Cray
+set_property(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS TRUE)
+set(CMAKE_SHARED_LIBRARY_PREFIX lib)
+set(CMAKE_SHARED_LIBRARY_SUFFIX .so)
+set(CMAKE_STATIC_LIBRARY_PREFIX lib)
+set(CMAKE_STATIC_LIBRARY_SUFFIX .a)
+
+set(CMAKE_FIND_LIBRARY_PREFIXES lib)
+set(CMAKE_FIND_LIBRARY_SUFFIXES .so .a)
+
+# Make sure we have the appropriate environment loaded
+if(NOT DEFINED ENV{SYSROOT_DIR})
+ message(FATAL_ERROR The SYSROOT_DIR environment variable is not defined but the ComputeNodeLinux CMake platform module requires it. This usually means that the necessary PrgEnv-* module is not loaded)
+endif()
+
+# Set up system search paths that CMake will use to look for libraries and
+# include files. These will be the standard UNIX search paths but rooted
+# in the SYSROOT of the computes nodes.
+include(Platform/UnixPaths)
+set(CMAKE_FIND_ROOT_PATH $ENV{SYSROOT_DIR})
+set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
+set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
+set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
+set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
--
1.9.3
--
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
Re: [CMake] Generator-independent incremental CMake run
On 13. August 2014 21:40:34 MESZ, Nagger nag...@gmx.de wrote: But what I really miss is an --update option for CMake which is doing all the work (updating if possible, configuring if necessary) internally. It would use the implementation of 'cmake --build' to trigger a re-configure and if that is not possible it would start a fresh configuregenerate. Any thoughts about that? cmake $builddir does exactly that. The ZERO_CHECK visual studio target that is present in every cmake generated solution does this: it checks if cmake needs to be re-run. It is built before every other target. So your batch file does a lot of things that are already done by cmake. Well unless you explicitly disabled this. But you'd know then. HS -- 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] ctest and tracks
Hello, I've have configured a project to use dash to save test results. On thing is not clear in the ctest documentation: what is the use of the --track option ? Does it allow to create a new category (like Weekly) and submit the test results to this new category ? Best regards, YC -- 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] ctest and tracks
--track is the same as the TRACK argument to the ctest_start scripting command. http://www.cmake.org/cmake/help/v3.0/command/ctest_start.html It will send a dashboard to the named section of a CDash project page, but it will NOT create it. You have to create the track (called a group in the CDash admin pages) as the CDash project admin first before you can send to it. For example, on the VTK Wiki Examples dashboard, there is a Wiki Examples track/group/section, which was created by the project admin before dashboards were submitted to that track. http://open.cdash.org/index.php?project=VTKWikiExamples HTH, David C. -- 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] Regarding enviroment variables directly used in executables
Hi David,
In our cmake project, we have the following scenario:
1. add_custom_command() call is as follows:
add_custom_command(TARGET ${TESTTARGETNAME}
POST_BUILD
COMMENT Test
target 1...
COMMAND
python ${CMAKE_SOURCE_DIR}/testthetargets.bat TestTarget1 ${TESTBIN}
)
2. The code in the batch file testthetargets.bat is as follows:
It invokes a project specific executable testtarget1.exe.
The source code of testtarget1.exe has calls to get few environment variables
using getenv() function call.
For example, a sample getenv() call is as follows:
target2_exe_path = getenv(TARGET2_EXE_PATH);
So, here the above getenv() call is supposed to get the value of environment
variable TARGET2_EXE_PATH.
Issue we are facing is as follows:
1. We set environment variable TARGET2_EXE_PATH using the following cmake
SET command before the add_custom_command() execution:
SET(ENV{TARGET2_EXE_PATH} C:/Test/Target2)
2. But when the add_custom_command() gets executed, we observe that the
environment variable TARGET2_EXE_PATH is not getting reflected in the above
getenv() call in the source code of testtarget1.exe. The getenv() call returns
an empty string.
But this issue does not occur when TARGET2_EXE_PATH environment variable is set
from Windows directly (i.e. from System Properties - Advanced - Environment
Variables). In that case, TARGET2_EXE_PATH gets reflected in the above getenv()
call.
So, basically the call to SET(ENV{TARGET2_EXE_PATH} C:/Test/Target2) has no
impact on the call to getenv() in the source code.
Kindly let us know if there is any other way in this case other than setting
the TARGET2_EXE_PATH environment variable from Windows directly ?
Thanks Regards
Ravi Raman
Xoriant Solutions Pvt. Ltd
4th Floor, Winchester, Hiranandani Business Park, Powai, Mumbai 400076, INDIA.
Tel: +91 22 30511000,9930100026 Extn: 2144 Voip No. 4088344495/96/97/98 Voip
Extn:1178| Fax: +91 22 3051
ravi.ra...@xoriant.commailto:ram.si...@xoriant.com|
http://www.xoriant.comhttp://www.xoriant.com/
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Regarding enviroment variables directly used in executables
A SET(ENV{TARGET2_EXE_PATH} C:/Test/Target2) call in a CMakeLists
file only has an effect while CMake is running.
If you need the env var set for your batch file to run, you should pass
the value for it down in as an arg to the batch file, and then do:
set TARGET2_EXE_PATH=%~1
(no quotes in the batch file set, %~1 means arg 1 to the batch file,
but with any surrounding quotes stripped...)
HTH,
David
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] ctest and tracks
OK, thanks for the informations. It's a lot more clear now. YC - Mail original - De: David Cole dlrd...@aol.com À: ycollette nospam ycollette.nos...@free.fr, cmake@cmake.org Envoyé: Jeudi 14 Août 2014 13:33:01 Objet: Re: [CMake] ctest and tracks --track is the same as the TRACK argument to the ctest_start scripting command. http://www.cmake.org/cmake/help/v3.0/command/ctest_start.html It will send a dashboard to the named section of a CDash project page, but it will NOT create it. You have to create the track (called a group in the CDash admin pages) as the CDash project admin first before you can send to it. For example, on the VTK Wiki Examples dashboard, there is a Wiki Examples track/group/section, which was created by the project admin before dashboards were submitted to that track. http://open.cdash.org/index.php?project=VTKWikiExamples HTH, David C. -- 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] Generator-independent incremental CMake run
Am 14.08.2014 08:13, schrieb Hendrik Sattler: On 13. August 2014 21:40:34 MESZ, Nagger nag...@gmx.de wrote: But what I really miss is an --update option for CMake which is doing all the work (updating if possible, configuring if necessary) internally. It would use the implementation of 'cmake --build' to trigger a re-configure and if that is not possible it would start a fresh configuregenerate. Any thoughts about that? cmake $builddir does exactly that. This does not work here. cmake $builddir does a full configuregenerate. (CMake version is 2.8.12) We have a fairly large project with about 400 targets. $ cmake %builddir% - takes about 5 minutes for a No-op $ cmake --build %builddir% --target ZERO_CHECK - takes 20 seconds for No-op The ZERO_CHECK visual studio target that is present in every cmake generated solution does this: it checks if cmake needs to be re-run. It is built before every other target. So your batch file does a lot of things that are already done by cmake. If the build is started from command line (cmake --build or msbuild directly) your wont get the Project has changed! Abort and Reload?-Dialog. The old solution will be build. You need to execute the build-process a seconds time. Or - as the script does - start a separate ZERO_CHECK before the actual build. Marc -- 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] Generator-independent incremental CMake run
We have a fairly large project with about 400 targets. $ cmake %builddir% - takes about 5 minutes for a No-op $ cmake --build %builddir% --target ZERO_CHECK - takes 20 seconds for No-op This is the problem. cmake %builddir% should be as fast as possible for a no-op... If it's not, it would be good to solve the real underlying problem that causes it to take 5 minutes for nothing rather than write elaborate scripts to try to workaround it. Is your project publicly available so CMake devs can try to figure out why it takes so long? Or... can you produce a generated repro case that demonstrates a long no-op time? There must be something in your project's CMake code that triggers the performance problem. Does it still happen with the latest release (CMake 3.0.1)? D -- 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] Generator-independent incremental CMake run
Am 14.08.2014 16:31, schrieb David Cole: We have a fairly large project with about 400 targets. $ cmake %builddir% - takes about 5 minutes for a No-op $ cmake --build %builddir% --target ZERO_CHECK - takes 20 seconds for No-op This is the problem. cmake %builddir% should be as fast as possible for a no-op... If it's not, it would be good to solve the real underlying problem that causes it to take 5 minutes for nothing rather than write elaborate scripts to try to workaround it. I already had a look into our large generation time. They are multiple reasons, not one big issue which can be solved easily. But with all due respect, its not just a 'workaround'. I do not want to re-compile things that haven't changed, so i also do not want to re-generate if nothing has changed. A ZERO_CHECK (comparing timestamps of all used CMakeLists.txt) will always be faster than generating the project. Test with CMake 3.0.1 configuring CMake itself: $ git describe v3.0.1-1690-geb3b550 $ cmake --version cmake version 3.0.1 CMake suite maintained and supported by Kitware (kitware.com/cmake). $ time cmake build -- Configuring done -- Generating done -- Build files have been written to: D:/Playground/cmake/cmake/build real0m14.414s user0m0.000s sys 0m0.015s $ time cmake --build build --target ZERO_CHECK Microsoft (R) Build Engine version 4.0.30319.17929 [] real0m0.421s user0m0.000s sys 0m0.015s So ZERO_CHECK is 34 times faster. Why shouldn't I take advantage of that. Thank, Marc -- 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] Generator-independent incremental CMake run
On 8/14/2014 11:26 AM, Nagger wrote:
So ZERO_CHECK is 34 times faster. Why shouldn't I take advantage of that.
If CMake does not need to re-run, then ZERO_CHECK will always be faster
than cmake build_dir. cmake build_dir will run a full configure and
generate no matter what. That said, a cmake --build all, should do the
same thing. Going back to your original question:
For our Continuous Integration tests we need fast incremental builds (only
build what has changed).
This also includes that CMake only has to run if necessary (some CMakeLists.txt
changed).
It seems there is no beautiful/portable/generator-independent way to do this?!
The way to do this is to use a ctest script. You can basically do all
the stuff in your batch script. It would be something like this:
if(NOT EXISTS ${BULD_TREE)
do_configure_and_build()
endif()
function(do_configure_and_build)
ctest_update()
ctest_configure()
ctest_build()
endfunction()
Usually, it should be enough to have your version control system tell
you if something has really changed. If so, you will want to do a
configure/build.
-Bill
--
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] Resetting CMAKE_Fortran_FLAGS for a specific file
In my opinion this is a deficiency in how cmake currently works with object
libraries. If one of the source files in an object library depends on a
third library then it should be possible to specify that in the link
interface of either the object library or the source file. It is wrong to
have to specify the dependency multiple times for every library or
executable that uses the object library. It is a property of the object
library, not the users of the object library.
I believe there is already a enhancement request open for something like
this.
--
Glenn
On 13 August 2014 15:44, marco restelli mreste...@gmail.com wrote:
2014-08-13 16:16 GMT+0200, Mark Abraham mark.j.abra...@gmail.com:
On Wed, Aug 13, 2014 at 7:12 AM, marco restelli mreste...@gmail.com
wrote:
2014-08-13 15:53 GMT+0200, Mark Abraham mark.j.abra...@gmail.com:
On Wed, Aug 13, 2014 at 3:18 AM, marco restelli mreste...@gmail.com
wrote:
Hi Petr,
thanks, very informative!
2014-08-13 9:20 GMT+0200, Petr Kmoch petr.km...@gmail.com:
Hi Marco.
Sane compilers allow later command-line options to override earlier
ones,
so what you're doing should be fine. Unfortunately, I know some
Fortran
compilers are not sane in this regard.
Here, I would really like to reduce as much as possible the flags
regardless of the chosen compiler, so undoing the chosen flags
seems to me cumbersome and compiler dependent, compared to resetting
them altogether. I like the idea of OBJECT libraries better (it also
solves other problems I have, I did not know about it!).
If you really need to solve this by explicitly modifying the global
list
for a particular file, the only thing I can think of is move those
files
to
a separate CMakeList and turn them into an object library:
This almost works, I have a problem specifying liking dependencies
for
the OBJECT libraries. With a normal library, I can use
TARGET_LINK_LIBRARIES( my_library ${other_libs_my_library_depends_on}
)
but if my_library is OBJECT I see the error
Object library target my_library may not link to anything.
See http://www.cmake.org/cmake/help/v3.0/command/add_library.html for
the
correct way to do things with object libraries - for this purpose,
they
are
closer to source files than libraries, which makes sense given that
there's
not actually a library written to disk anywhere.
Mark, thanks, but here I don't find anything that answers my question,
namely specifying that my OBJECT library (i.e. the files included in
it) require other libraries for linking.
The object library is never linked, so the issue of linking with it or to
it does not arise. The targets that use the object library have
transitive
linking dependencies, just like you had if the source files in the object
library had been directly specified as part of those targets.
OK, let me see if I understad it. Using the example in
http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library
let us say I have
# A/CMakeLists.txt
add_library(A OBJECT ${A_srcs})
# B/CMakeLists.txt
add_library(B OBJECT ${B_srcs})
# CMakeLists.txt
add_subdirectory(A)
add_subdirectory(B)
add_library(big ${other_srcs} $TARGET_OBJECTS:A $TARGET_OBJECTS:B)
and I know that whenever I link the files listed in ${A_srcs}, i.e.
whenever I likd the OBJECT library A, I also need to link
libsomeotherlibrary.a . Then in the main CMakeLists.txt I add
TARGET_LINK_LIBRARIES( big someotherlibrary )
right?
Moreover, there is no way to specify someotherlibrary in
A/CMakeLists.txt, it has to be done where I define the target big,
namely in the main CMakeLists.txt. Is this correct?
Thanks,
Marco
--
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:
Re: [CMake] Windows RC files with Ninja
I found a workaround. Turns out that the issue is caused when not enabling C language support in the project() command. i.e I was doing cmake_minimum_required( VERSION 3.0.0 ) project( proj CXX) Changing this to cmake_minimum_required( VERSION 3.0.0 ) project( proj CXX) fixes the issue. http://public.kitware.com/Bug/view.php?id=15088 Frank -Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Miller, Frank Sent: Tuesday, August 12, 2014 11:44 AM To: CMake MailingList Subject: [CMake] Windows RC files with Ninja Greetings, I tried to move from 2.8 to 3.0.1 today and I'm experiencing an issue with RC files. Looks like a simple problem but I would be baffled if I'm the first to experience this so I expect I have some kind of configuration issue. Here is the offending snippet in the rules.ninja file: rule RC_COMPILER depfile = $DEP_FILE deps = gcc command = RC $in $DEP_FILE $out c:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/cl.exe c:\PROGRA~2\WI3CF2~1\8.1\bin\x86\rc.exe $FLAGS $DEFINES /fo$out $in description = Building RC object $out If I put the path to cmcldeps.exe in the empty quotes on the command line, it works as expected. Does anyone else have this problem? Frank This communication, including any attachments, may contain information that is proprietary, privileged, confidential or legally exempt from disclosure. If you are not a named addressee, you are hereby notified that you are not authorized to read, print, retain a copy of or disseminate any portion of this communication without the consent of the sender and that doing so may be unlawful. If you have received this communication in error, please immediately notify the sender via return e-mail and delete it from your system. In order to safeguard its employee data as well as sensitive patient, customer, business, legal and other information, the company uses all lawful means, under all applicable law, to access, monitor, preserve, collect and review all communications between employees and all other users only when, and to the extent necessary, to fulfill investigatory and other important business and legal responsibilities. By responding to this communication, or initiating additional co mmunication with the company, you consent to such lawful monitoring, to the extent such consent is required and valid in your local area. -- 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 This communication, including any attachments, may contain information that is proprietary, privileged, confidential or legally exempt from disclosure. If you are not a named addressee, you are hereby notified that you are not authorized to read, print, retain a copy of or disseminate any portion of this communication without the consent of the sender and that doing so may be unlawful. If you have received this communication in error, please immediately notify the sender via return e-mail and delete it from your system. In order to safeguard its employee data as well as sensitive patient, customer, business, legal and other information, the company uses all lawful means, under all applicable law, to access, monitor, preserve, collect and review all communications between employees and all other users only when, and to the extent necessary, to fulfill investigatory and other important business and legal responsibilities. By responding to this communication, or initiating additional co mmunication with the company, you consent to such lawful monitoring, to the extent such consent is required and valid in your local area. -- 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] Viewing the full build log from the CDash Dashboard
Apologies if this is a stupid question with an obvious answer staring me in the face but... How does one view the full build log from the dashboard? This relates to our own dashboard but looking at a build of CMake as an example (http://open.cdash.org/buildSummary.php?buildid=3450103) The full output of the configure step seems to be displayed on the buildSummary page but there's nothing for the actual build (gmake in this case) step. CDash will show a cut-down summary of where it thinks the errors or warnings are but sometimes (especially with parallel builds) these are wrong (or false positives) or alternatively everything succeeded but you still want to browse through the build output. Our current build system captures the output of the ctest process and emails it separately but surely this must be available through CDash? Thanks Matt -- 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] Using a custom preprocessor
Hi! I am currently working on a project which uses plain old make as a build system. Needless to say, adding new compilers etc. is a lot of work, so I would like to start using CMake, which I have had excellent experience with in the past. There is one peculiarity that I do not know how to handle. Some of our code (C and Fortran) is contained in files that end with .cs or .fs, which are run through an in-house preprocessor. A Makefile target is then something along the lines of (but not exactly) foo.o: foo.f $(FC) -c $(FFLAGS) foo.f foo.f: foo.fs custom_preproc foo.fs -o foo.f Is it possible to, somehow, add this pre-compilation step for such files, and then add_executable(myexe foo.fs bar.cs main.f90) ? Cheers, Paul -- 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.0.1-1691-g5fc8e66
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 5fc8e666fb07c3efd930c53d9134922fbd27ae56 (commit) from eb3b5501c01a40aa592e512bc61fbe4f1cb1e2cc (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5fc8e666fb07c3efd930c53d9134922fbd27ae56 commit 5fc8e666fb07c3efd930c53d9134922fbd27ae56 Author: Kitware Robot kwro...@kitware.com AuthorDate: Fri Aug 15 00:01:06 2014 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Fri Aug 15 00:01:06 2014 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 2d1d2ef..0a7cd91 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 0) -set(CMake_VERSION_PATCH 20140814) +set(CMake_VERSION_PATCH 20140815) #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
