Re: [cmake-developers] Setting includes, defines and other usage requirements with one command
Brad King wrote: I've implemented it in the tll-includes-defines branch in my clone. I've only tested it manually though. Yes, that looks good. Please add tests covering each case: I've pushed it again to my clone. Once the fix-target-property-commands topic is in master, we can rebase it if needed and get it merged to next. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting includes, defines and other usage requirements with one command
On 01/30/2013 03:15 AM, Stephen Kelly wrote:
Brad King wrote:
I've implemented it in the tll-includes-defines branch in my clone. I've
only tested it manually though.
Yes, that looks good. Please add tests covering each case:
I've pushed it again to my clone.
Once the fix-target-property-commands topic is in master, we can rebase it
if needed and get it merged to next.
I just tried your branch with a simple test case:
--
cmake_minimum_required(VERSION 2.8.10.20130129)
project(FOO C)
set(CMAKE_INSTALL_PREFIX ${FOO_BINARY_DIR}/root)
add_library(foo SHARED foo.c)
target_include_directories(foo PUBLIC
$BUILD_INTERFACE:${FOO_SOURCE_DIR}
$INSTALL_INTERFACE:$INSTALL_PREFIX/include
)
add_library(bar SHARED bar.c)
#set(m m) # uncommenting breaks this
target_link_libraries(bar LINK_PUBLIC foo ${m})
get_property(iface TARGET bar PROPERTY INTERFACE_INCLUDE_DIRECTORIES)
message(STATUS bar.INTERFACE_INCLUDE_DIRECTORIES = [${iface}])
export(TARGETS bar foo FILE Targets.cmake)
install(TARGETS bar foo DESTINATION lib EXPORT Foo)
install(EXPORT Foo DESTINATION lib/cmake/foo)
--
It works, but then uncommenting the marked line to tll a non-target
produces:
-- bar.INTERFACE_INCLUDE_DIRECTORIES =
[$TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES;$$TARGET_DEFINED:m:$TARGET_PROPERTY:m,INTERFACE_INCLUDE_DIRECTORIES]
CMake Error at CMakeLists.txt:16 (export):
$TARGET_PROPERTY:m,prop requires its first parameter to be a reachable
target.
The TARGET_PROPERTY errors out even though TARGET_DEFINED:m should
be false.
Also, will the non-target expressions added by tll be preprocessed out
during export()/install(EXPORT)?
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting includes, defines and other usage requirements with one command
Brad King wrote: On 01/30/2013 03:15 AM, Stephen Kelly wrote: Brad King wrote: I've implemented it in the tll-includes-defines branch in my clone. I've only tested it manually though. Yes, that looks good. Please add tests covering each case: I've pushed it again to my clone. Once the fix-target-property-commands topic is in master, we can rebase it if needed and get it merged to next. I just tried your branch with a simple test case: It works, but then uncommenting the marked line to tll a non-target produces: -- bar.INTERFACE_INCLUDE_DIRECTORIES = [$TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES; $$TARGET_DEFINED:m:$TARGET_PROPERTY:m,INTERFACE_INCLUDE_DIRECTORIES] CMake Error at CMakeLists.txt:16 (export): $TARGET_PROPERTY:m,prop requires its first parameter to be a reachable target. That was fixed in fix-TARGET_PROPERTY-extraction, which was merged yesterday. Now that fix-target-property-commands was merged to master, I've rebased tll-includes-defines to master and your testcase works. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting includes, defines and other usage requirements with one command
On 01/30/2013 10:57 AM, Stephen Kelly wrote:
Now that fix-target-property-commands was merged to master, I've rebased
tll-includes-defines to master and your testcase works.
Thanks. However, now it leaks out all non-targets referenced by tll
as giant strings in the exported interfaces:
if(NOT ${CMAKE_FIND_PACKAGE_NAME}_NO_INTERFACES)
set_target_properties(bar PROPERTIES
INTERFACE_COMPILE_DEFINITIONS
$TARGET_PROPERTY:foo,INTERFACE_COMPILE_DEFINITIONS;$$TARGET_DEFINED:m:$TARGET_PROPERTY:m,INTERFACE_COMPILE_DEFINITIONS
INTERFACE_INCLUDE_DIRECTORIES
$TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES;$$TARGET_DEFINED:m:$TARGET_PROPERTY:m,INTERFACE_INCLUDE_DIRECTORIES
)
endif()
This is not acceptable. We need to recognize when something was added
by tll and was not a target and remove it from the non-linking interfaces.
Can export() and install(EXPORT) do partial evaluation to remove these?
We can document that $TARGET_DEFINED has scope only in the current
project and will be processed away during export. I do not think we
want an upstream interface modifying its behavior based on the mere
presence of an arbitrary target in the downstream anyway.
Other thoughts:
* The $INSTALL_PREFIX expression should evaluate as an error if
it is ever reached by any path except install(EXPORT). Otherwise
the empty string in $INSTALL_PREFIX/somewhere is unlikely to
do the right thing.
* If exported interfaces were partially evaluated then $INSTALL_PREFIX
could be handled with a real evaluation instead of string replacement.
* Transitive linking is handled in C++ code rather than in generator
expressions so there is no bloat in the LINK_LIBRARIES properties
for non-target elements like the above. Perhaps we can have a special
generator expression that has context-sensitive evaluation e.g.
$LINKED:blah
tll() would add this to COMPILE_DEFINITIONS and INCLUDE_DIRECTORIES
properties where it would be evaluated to get relevant target interface
properties. In other contexts it would be an empty string (or error?).
It could be preprocessed out during export and replaced by nothing for
non-targets or the relevant $TARGET_PROPERTY:... for targets.
* To optimize the large strings these interfaces generate, perhaps
properties can be represented in general as compiled generator
expressions that do not directly store their original strings but
have references to pieces of them and can reconstruct them.
This can be done later though.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting includes, defines and other usage requirements with one command
Brad King wrote:
On 01/30/2013 10:57 AM, Stephen Kelly wrote:
Now that fix-target-property-commands was merged to master, I've rebased
tll-includes-defines to master and your testcase works.
Thanks. However, now it leaks out all non-targets referenced by tll
as giant strings in the exported interfaces:
if(NOT ${CMAKE_FIND_PACKAGE_NAME}_NO_INTERFACES)
set_target_properties(bar PROPERTIES
INTERFACE_COMPILE_DEFINITIONS
$TARGET_PROPERTY:foo,INTERFACE_COMPILE_DEFINITIONS;
$$TARGET_DEFINED:m:$TARGET_PROPERTY:m,INTERFACE_COMPILE_DEFINITIONS
INTERFACE_INCLUDE_DIRECTORIES
$TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES;
$$TARGET_DEFINED:m:$TARGET_PROPERTY:m,INTERFACE_INCLUDE_DIRECTORIES
)
endif()
This is not acceptable. We need to recognize when something was added
by tll and was not a target and remove it from the non-linking interfaces.
Can export() and install(EXPORT) do partial evaluation to remove these?
As preprocessing is how things like that are done so far, I think using
preprocessing is the more straightforward way to do this at the moment. At
some point in the future we can see if partial evaluation is possible. It
would be possible to do in a later release if it is possible at all.
We can document that $TARGET_DEFINED has scope only in the current
project and will be processed away during export. I do not think we
want an upstream interface modifying its behavior based on the mere
presence of an arbitrary target in the downstream anyway.
Other thoughts:
* The $INSTALL_PREFIX expression should evaluate as an error if
it is ever reached by any path except install(EXPORT). Otherwise
the empty string in $INSTALL_PREFIX/somewhere is unlikely to
do the right thing.
Right. I've added a patch to that effect now.
* If exported interfaces were partially evaluated then $INSTALL_PREFIX
could be handled with a real evaluation instead of string replacement.
* Transitive linking is handled in C++ code rather than in generator
expressions so there is no bloat in the LINK_LIBRARIES properties
for non-target elements like the above. Perhaps we can have a special
generator expression that has context-sensitive evaluation e.g.
$LINKED:blah
That makes sense to me. I don't have time to do it right now though. Maybe I
can do it later.
tll() would add this to COMPILE_DEFINITIONS and INCLUDE_DIRECTORIES
properties where it would be evaluated to get relevant target interface
properties. In other contexts it would be an empty string (or error?).
It could be preprocessed out during export and replaced by nothing for
non-targets or the relevant $TARGET_PROPERTY:... for targets.
* To optimize the large strings these interfaces generate, perhaps
properties can be represented in general as compiled generator
expressions that do not directly store their original strings but
have references to pieces of them and can reconstruct them.
This can be done later though.
Perhaps. We'll have to keep the fact that not all properties can contain
generator expressions, but that should be possible. All for the future
though.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting includes, defines and other usage requirements with one command
On 01/30/2013 12:09 PM, Stephen Kelly wrote: This is not acceptable. We need to recognize when something was added by tll and was not a target and remove it from the non-linking interfaces. Can export() and install(EXPORT) do partial evaluation to remove these? As preprocessing is how things like that are done so far, I think using preprocessing is the more straightforward way to do this at the moment. At some point in the future we can see if partial evaluation is possible. It would be possible to do in a later release if it is possible at all. Okay, if preprocessing is sufficient to get rid of those then go for it. We can document that $TARGET_DEFINED has scope only in the current project and will be processed away during export. I do not think we want an upstream interface modifying its behavior based on the mere presence of an arbitrary target in the downstream anyway. Thoughts on this behavior? Another thought is to have tll() only append includes/defines if the target is already defined at the call site and otherwise do nothing. When I previously pointed out the need for handling not-yet-defined targets I did not realize the cost. We could even go as far as not adding the generator expression to INCLUDE_DIRECTORIES if the target dependency does not have an INTERFACE_INCLUDE_DIRECTORIES already defined too (and similarly for COMPILE_DEFINITIONS). Advantages: * Very little overhead for non-target arguments * Very little overhead for targets without interfaces * Works in the motivating case of using targets imported from an upstream Disadvantages: * Does not work automatically for circular dependencies. I think the disadvantage is okay because circular dependencies are a less common case and one can always make it work by writing out the generator expression manually. We should not make everyone pay the cost for supporting circular interfaces when few are using them. We can't even define circular interfaces through tll() anyway except for static libraries. * The $INSTALL_PREFIX expression should evaluate as an error if it is ever reached by any path except install(EXPORT). Otherwise the empty string in $INSTALL_PREFIX/somewhere is unlikely to do the right thing. Right. I've added a patch to that effect now. Thanks. * Transitive linking is handled in C++ code rather than in generator expressions so there is no bloat in the LINK_LIBRARIES properties for non-target elements like the above. Perhaps we can have a special generator expression that has context-sensitive evaluation e.g. $LINKED:blah That makes sense to me. I don't have time to do it right now though. Maybe I can do it later. Perhaps there is no need for it if we use the simpler approach above. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] CMAKE_lang_COMPILER_ID not set on Darwin
I was looking for a way to identify the compiler as clang to know if I should pass it a clang specific flag (-x c++). On Darwin default compiler is Clang used through /usr/bin/cc and and /usr/bin/c++. The identification is clearly signaled as Clang 4.1.0 but CMAKE_CXX_COMPILER_ID is not set. Obviously CMAKE_CXX_COMPILER is set to /usr/bin/c++. Given my belief that CMAKE_CXX_COMPILER_ID will not be implemented soon, what are my options? Thomas -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE_lang_COMPILER_ID not set on Darwin
We use this if(CMAKE_C_COMPILER MATCHES clang OR CMAKE_CXX_COMPILER MATCHES clang) set(COMPILING_WITH_CLANG True) elseif(CMAKE_C_COMPILER MATCHES .*gcc.* OR CMAKE_CXX_COMPILER MATCHES .*g[+][+].*) set(COMPILING_WITH_GCC True) endif() In our project On 2013-30-01, at 14:42:05 , Thomas Nilsson wrote: I was looking for a way to identify the compiler as clang to know if I should pass it a clang specific flag (-x c++). On Darwin default compiler is Clang used through /usr/bin/cc and and /usr/bin/c++. The identification is clearly signaled as Clang 4.1.0 but CMAKE_CXX_COMPILER_ID is not set. Obviously CMAKE_CXX_COMPILER is set to /usr/bin/c++. Given my belief that CMAKE_CXX_COMPILER_ID will not be implemented soon, what are my options? Thomas -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE_lang_COMPILER_ID not set on Darwin
CMAKE_CXX_COMPILER_ID should be set with CMake 2.8.10.2 and later... What version of CMake are you using? -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack different libraries in DEB compared to RPM
Hi, On Wed, Jan 30, 2013 at 08:45:31AM -0500, cmake-requ...@cmake.org wrote: Date: Tue, 29 Jan 2013 19:06:27 +0100 From: Eric Noulard eric.noul...@gmail.com Subject: Re: [CMake] CPack different libraries in DEB compared to RPM 2013/1/29 upprc04 uppr...@gmail.com: I'm running across an issue where I have some utility libraries that are only needed in the debian. I currently have them added to both the debian and RPM using CPack and CMake. What would I need to change in my CMake files to include a specific set of libraries to only be included in the debian and not included in the RPM. You just have to not install (or even not build) the deb-specific part when building for RPM. It is easily done with separate build-tree, You may use CPACK_PROJECT_CONFIG_FILE and override CPACK_INSTALL_CMAKE_PROJECTS in RPM/DEB specific sections. In that later case you need to define appropriate COMPONENT (see install(... COMPONENT...) argument ) in order to be able to install only the needed ones in each case. Exactly. My opinion is that DEB/RPM switching is best done by building and packaging on the actual most compatible system only (rather than using foreign-package creation on very foreign systems, i.e. multiple more or less foreign CPack generators). Separate systems of course directly translates into separate build trees, too. Thus there's no problem in either adding distribution detection heuristics to CMake configure-time, perhaps via find_file(/etc/debian_version) (to skip build / install() of the affected library), or to fix it up at CPack time, via a user-custom CPackOptions.cmake (I think) file. Also, note that building should in most cases be done on the *oldest* (or perhaps near-oldest?) system version which is desired to be supported, not a dangerously new one (reason being that backwards compatibility support to old packages is far more commonplace/easier than rather spotty forward compatibility). Of course ideally one would offer precisely tailored packages via each version of these systems, but that's a large overhead that's probably a pipe dream in many situations. Andreas Mohr -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] ctest and properties
Hello, I am currently working with ctest. I am trying to get, via the command line help, all the properties available for TEST. For example: set_properties(TEST test_1 PROPERTY ??? test_2) If I do a ctest --help-command set_property, only the command is detailed, but no properties are displayed. Is there a way to get help on properties via command line ? Best regards, YC -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ctest and properties
On 1/30/2013 10:14 AM, ycollette.nos...@free.fr wrote: Hello, I am currently working with ctest. I am trying to get, via the command line help, all the properties available for TEST. For example: set_properties(TEST test_1 PROPERTY ??? test_2) If I do a ctest --help-command set_property, only the command is detailed, but no properties are displayed. Is there a way to get help on properties via command line ? Best regards, YC cmake --help-command set_property. It is a cmake command in the context you are using it. -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ctest and properties
Thanks for the answer. In fact, the information I am looking for is located in cmake-2.8.10/2/Source/cmTest.cxx in the method void cmTest::DefineProperties(cmake *cm) line 98. I really don't know how to get this help from command line. I know that this information is context dependent (whether you use it from cmake or from test, on some kind of object like TEST in my case). YC - Mail original - De: Bill Hoffman bill.hoff...@kitware.com À: cmake@cmake.org Envoyé: Mercredi 30 Janvier 2013 16:42:48 Objet: Re: [CMake] ctest and properties On 1/30/2013 10:14 AM, ycollette.nos...@free.fr wrote: Hello, I am currently working with ctest. I am trying to get, via the command line help, all the properties available for TEST. For example: set_properties(TEST test_1 PROPERTY ??? test_2) If I do a ctest --help-command set_property, only the command is detailed, but no properties are displayed. Is there a way to get help on properties via command line ? Best regards, YC cmake --help-command set_property. It is a cmake command in the context you are using it. -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ctest and properties
Yes, this link is really valuable. I add it in my book mark. I didn't find it when I went on the website (maybe a mistake from my side ...). Thanks a lot. YC - Mail original - De: David Cole dlrd...@aol.com À: ycollette nospam ycollette.nos...@free.fr Cc: cmake@cmake.org Envoyé: Mercredi 30 Janvier 2013 16:53:32 Objet: Re: [CMake] ctest and properties T he best test properties reference is available online at: http://cmake.org/cmake/help/v2.8.10/cmake.html#section_PropertiesonTests You can't get that same information from the ctest command line as of 2.8.10. The cte st command line help could use some love... -Original Message- From: ycollette.nospam ycollette.nos...@free.fr Cc: cmake cmake@cmake.org Sent: Wed, Jan 30, 2013 10:47 am Subject: Re: [CMake] ctest and properties Thanks for the answer. In fact, the information I am looking for is located in cmake-2.8.10/2/Source/cmTest.cxx in the method void cmTest::DefineProperties(cmake *cm) line 98. I really don't know how to get this help from command line. I know that this information is context dependent (whether you use it from cmake or from test, on some kind of object like TEST in my case). YC - Mail original - De: Bill Hoffman bill.hoff...@kitware.com À: cmake@cmake.org Envoyé: Mercredi 30 Janvier 2013 16:42:48 Objet: Re: [CMake] ctest and properties On 1/30/2013 10:14 AM, ycollette.nos...@free.fr wrote: Hello, I am currently working with ctest. I am trying to get, via the command line help, all the properties available for TEST. For example: set_properties(TEST test_1 PROPERTY ??? test_2) If I do a ctest --help-command set_property, only the command is detailed, but no properties are displayed. Is there a way to get help on properties via command line ? Best regards, YC cmake --help-command set_property. It is a cmake command in the context you are using it. -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ctest and properties
The best test properties reference is available online at: http://cmake.org/cmake/help/v2.8.10/cmake.html#section_PropertiesonTests You can't get that same information from the ctest command line as of 2.8.10. The ctest command line help could use some love... -Original Message- From: ycollette.nospam ycollette.nos...@free.fr Cc: cmake cmake@cmake.org Sent: Wed, Jan 30, 2013 10:47 am Subject: Re: [CMake] ctest and properties Thanks for the answer. In fact, the information I am looking for is located in cmake-2.8.10/2/Source/cmTest.cxx in the method void cmTest::DefineProperties(cmake *cm) line 98. I really don't know how to get this help from command line. I know that this information is context dependent (whether you use it from cmake or from test, on some kind of object like TEST in my case). YC - Mail original - De: Bill Hoffman bill.hoff...@kitware.com À: cmake@cmake.org Envoyé: Mercredi 30 Janvier 2013 16:42:48 Objet: Re: [CMake] ctest and properties On 1/30/2013 10:14 AM, ycollette.nos...@free.fr wrote: Hello, I am currently working with ctest. I am trying to get, via the command line help, all the properties available for TEST. For example: set_properties(TEST test_1 PROPERTY ??? test_2) If I do a ctest --help-command set_property, only the command is detailed, but no properties are displayed. Is there a way to get help on properties via command line ? Best regards, YC cmake --help-command set_property. It is a cmake command in the context you are using it. -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] add_jar()
Bumping my newbie question... I need to add a jar to the output of add_jar().
Anybody know how to do this?
Thanks, Rodrigo.
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
Pastrana, Rodrigo (RIS-BCT)
Sent: Tuesday, January 29, 2013 12:25 PM
To: 'cmake@cmake.org'
Subject: [CMake] Adding dependency jar to jar
Hello, I've been creating a jar based on my java project without issue, but now
I'm adding an external dependency and will like to package the said
dependency's contents within my output jar.
I'm able to build the project via CMAKE by adding the external.jar to the
CMAKE_JAVA_INCLUDE_PATH list:
LIST(APPEND CMAKE_JAVA_INCLUDE_PATH ${EXTERNAL_BUILDTIME_JAR})
ADD_JAR(${JAR_FILE} ${JAVA_SOURCE_FILES})
And I've tried a few things to include ${EXTERNAL_RUNTIME_JAR} in ${JAR_FILE}
to no avail.
Does anybody know a way to accomplish this? (btw using CMAKE 2.8).
Using ANT through eclipse I was able to include the external using
zipgroupfileset:
jar jarfile=myjavaproj.jar includes=**/*.class basedir=bin
zipgroupfileset dir=/XXX/yyy/zzz/ includes=external.jar/
/jar
Thanks in advance. RP.
-
The information contained in this e-mail message is intended only
for the personal and confidential use of the recipient(s) named
above. This message may be an attorney-client communication and/or
work product and as such is privileged and confidential. If the
reader of this message is not the intended recipient or an agent
responsible for delivering it to the intended recipient, you are
hereby notified that you have received this document in error and
that any review, dissemination, distribution, or copying of this
message is strictly prohibited. If you have received this
communication in error, please notify us immediately by e-mail, and
delete the original message.--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] So Long
Howdy folks, Thought I'd ping the CMake mailing lists one last time before I have to give up david.c...@kitware.com... ;-) For those of you that haven't heard yet, I've just embarked on a new adventure with a little startup company called Neocis Inc. I'll still be a big huge fan (and user) of CMake, and will take the way of the source with me wherever I go from now on. Heck, I bet you'll even see some commits coming from my direction now and again. CMake is too awesome not to use: it tries to take on the monumental, nearly impossible task of abstracting software build systems for dozens of platforms, and keep up to date with the new ones that come out, and does a quite admirable job. I trust this community will continue to provide stable, reliable, regular releases of CMake well into the future. In fact, I'm counting on it. So long and thanks for all the... ...patches! David Cole (still sorta reachable via dlrd...@aol.com) -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] So Long
On 1/30/13, David Cole david.c...@kitware.com wrote: Howdy folks, Thought I'd ping the CMake mailing lists one last time before I have to give up david.c...@kitware.com... ;-) For those of you that haven't heard yet, I've just embarked on a new adventure with a little startup company called Neocis Inc. I'll still be a big huge fan (and user) of CMake, and will take the way of the source with me wherever I go from now on. Heck, I bet you'll even see some commits coming from my direction now and again. CMake is too awesome not to use: it tries to take on the monumental, nearly impossible task of abstracting software build systems for dozens of platforms, and keep up to date with the new ones that come out, and does a quite admirable job. I trust this community will continue to provide stable, reliable, regular releases of CMake well into the future. In fact, I'm counting on it. So long and thanks for all the... ...patches! David Cole (still sorta reachable via dlrd...@aol.com) Wow, news to me. Congrats on the new job! And thanks for all you've done for CMake. Good luck on your next venture! -Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Visual Studio 2010 project not loading with 2.8.10
Hey there. I recently switched from CMAKE 2.8.7 to 2.8.10 and found that my new fresh generated vcxproj file does not load in VS 2010 where the old one generated by 2.8.7 loads correctly. I just gives a generic error that one or more projects could not be loaded. I want to move to 2.8.10 because it has more advanced generator expressions. What do I need to supply to you to help me figure out what the issue is? Thanks in advance for your help BA -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Configuration defining add_custom_command behavior
Hey there
I was hoping I'd find the answer online but there seems to be no way to do what
I want with the version of CMAKE I'm stuck with.
I'm currently using CMAKE 2.8.7 to generate a VS2010 solution and project. I'd
like to add a PRE_BUILD step that runs one set of commands for a debug build
and another for release. Here's a made up example of what I'd like to do
If we're in debug
ADD_CUSTOM_COMMAND (TARGET ${MY_PROJECT}
PRE_BUILD
COMMAND jam
ARGS -j8 -sDEBUG=1 ${MY_JAM_TARGET}
COMMENT Running JAM target: ${ MY_JAM_TARGET }
WORKING_DIRECTORY ${MY_BUILD_DIR}
VERBATIM)
And if we're in release
ADD_CUSTOM_COMMAND (TARGET ${MY_PROJECT}
PRE_BUILD
COMMAND jam
ARGS -j8 ${MY_JAM_TARGET}
COMMENT Running JAM target: ${ MY_JAM_TARGET }
WORKING_DIRECTORY ${MY_BUILD_DIR}
VERBATIM)
Note in release, we are not passing the argument -sDEBUG=1
Is there a way to do this in 2.8.7? I can't use 2.8.10 because it generates
vcxproj files that will not load in VS2010
Thanks in advance
BA
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Visual Studio 2010 project not loading with 2.8.10
On 1/30/2013 6:03 PM, Bryn Aspestrand wrote: Hey there. I recently switched from CMAKE 2.8.7 to 2.8.10 and found that my new fresh generated vcxproj file does not load in VS 2010 where the old one generated by 2.8.7 loads correctly. I just gives a generic error that one or more projects could not be loaded. I want to move to 2.8.10 because it has more advanced generator expressions. What do I need to supply to you to help me figure out what the issue is? Thanks in advance for your help Should work. Did you: - start from a clean build tree - pick the correct generator - does it work for a simple project add_library(foo foo.c) (where foo.c is an empty file) -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Visual Studio 2010 project not loading with 2.8.10
There's only one target and it's the one that fails -Original Message- From: Bill Hoffman [mailto:bill.hoff...@kitware.com] Sent: Wednesday, January 30, 2013 4:55 PM To: Bryn Aspestrand; cmake Subject: Re: [CMake] Visual Studio 2010 project not loading with 2.8.10 Putting this back on the cmake mailing list. On 1/30/2013 7:48 PM, Bryn Aspestrand wrote: Yes it does. I'd wager it has something to do with what I'm doing in my CMakeLists.txt. Nothing strange. Just lots of SOURCE_GROUP's, perforce integration and some Qt moc and uic calls from macros. The project is big but not complicated. I took a quick look at the diff between the 2.8.7 generated vcxproj file and the one generated by 2.8.10. The vast majority of the changes were moved ClInclude/ClCompile tags, relative paths replacing absolute paths and the ProgramDataBaseFileName tag changing to ProgramDataBaseFile I know that's not much help. The generator I'm using is Visual Studio 10 Is there a way to analyze the generated vcxproj file to see what the errors are? One thing you could try is to load the .vcxproj files individually and see if there is a particular target that is causing the trouble. -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Visual Studio 2010 project not loading with 2.8.10
Hi, On Wed, Jan 30, 2013 at 07:56:23PM -0500, cmake-requ...@cmake.org wrote: From: Bryn Aspestrand baspestr...@sugarsync.com Subject: [CMake] Visual Studio 2010 project not loading with 2.8.10 Hey there. I recently switched from CMAKE 2.8.7 to 2.8.10 and found that my new fresh generated vcxproj file does not load in VS 2010 where the old one generated by 2.8.7 loads correctly. I just gives a generic error that one or more projects could not be loaded. I want to move to 2.8.10 because it has more advanced generator expressions. What do I need to supply to you to help me figure out what the issue is? I think the quickest way is to keep a copy of the broken .vcxproj file, then revert to a CMake version which works (I'd recommend to try 2.8.9 first, to minimize change candidates), then keep a copy of the working .vcxproj file, too. Then either use diff to figure out the changed/added parts, or figure them out manually (obviously less reliable), or send both files to someone who can analyze it this way. Thanks for the report! Andreas Mohr -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] So Long
Hi, On Wed, Jan 30, 2013 at 07:56:23PM -0500, cmake-requ...@cmake.org wrote: From: David Cole david.c...@kitware.com Howdy folks, Thought I'd ping the CMake mailing lists one last time before I have to give up david.c...@kitware.com... ;-) For those of you that haven't heard yet, I've just embarked on a new adventure with a little startup company called Neocis Inc. Aww shucks, what a loss! The Kitware team has been doing a very admireable job at maintaining the CMake beast (pig? ;) and being very reactive. Thus it's quite sad to see a rather sizeable part of this success moving on. Anyway, I'm sure you have very good reasons for changing tracks - sometimes in life one needs to embrace new challenges. CMake is too awesome not to use: it tries to take on the monumental, nearly impossible task of abstracting software build systems for dozens of platforms, and keep up to date with the new ones that come out, and does a quite admirable job. I trust this community will continue to provide stable, reliable, regular releases of CMake well into the future. In fact, I'm counting on it. There's nothing to add to that. David Cole (still sorta reachable via dlrd...@aol.com) Good luck! Andreas Mohr -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] CTEST_CUSTOM_TESTS_IGNORE regex?
In CTestCustom.cmake, I use CTEST_CUSTOM_MEMCHECK_IGNORE and
CTEST_CUSTOM_TESTS_IGNORE to turn some long-running tests on and off (on
for nightlies, off for development test cycles).
I recently broke apart a rather large shell script that was used to run a
test under many scenarios into something like
foreach (a 0 1)
foreach (b 0 1)
foreach (c 0 1)
add_test(NAME big_test_${a}${b}${c} COMMAND big_test ${a} ${b} ${c})
endforeach (c)
endforeach (b)
endforeach (a)
...you get the idea. It generates somewhere in the realm of 2000 test
cases. Now they run in parallel, which is great, but I can no longer turn
off this suite of tests easily.
It would be great to do something like
list(APPEND CTEST_CUSTOM_TESTS_IGNORE 'big_test_.*')
Is this or something like it supported?
I haven't tried it yet so maybe it just works, but I kind of doubt it.
I didn't see anything pop out in the docs but maybe I missed it.
--
Cheers,
Leif
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ctest and properties
What about a new -help command: --help-properties ? Do I fill a bug report for that ? YC - Mail original - De: David Cole dlrd...@aol.com À: ycollette nospam ycollette.nos...@free.fr Cc: cmake@cmake.org Envoyé: Mercredi 30 Janvier 2013 16:53:32 Objet: Re: [CMake] ctest and properties T he best test properties reference is available online at: http://cmake.org/cmake/help/v2.8.10/cmake.html#section_PropertiesonTests You can't get that same information from the ctest command line as of 2.8.10. The cte st command line help could use some love... -Original Message- From: ycollette.nospam ycollette.nos...@free.fr Cc: cmake cmake@cmake.org Sent: Wed, Jan 30, 2013 10:47 am Subject: Re: [CMake] ctest and properties Thanks for the answer. In fact, the information I am looking for is located in cmake-2.8.10/2/Source/cmTest.cxx in the method void cmTest::DefineProperties(cmake *cm) line 98. I really don't know how to get this help from command line. I know that this information is context dependent (whether you use it from cmake or from test, on some kind of object like TEST in my case). YC - Mail original - De: Bill Hoffman bill.hoff...@kitware.com À: cmake@cmake.org Envoyé: Mercredi 30 Janvier 2013 16:42:48 Objet: Re: [CMake] ctest and properties On 1/30/2013 10:14 AM, ycollette.nos...@free.fr wrote: Hello, I am currently working with ctest. I am trying to get, via the command line help, all the properties available for TEST. For example: set_properties(TEST test_1 PROPERTY ??? test_2) If I do a ctest --help-command set_property, only the command is detailed, but no properties are displayed. Is there a way to get help on properties via command line ? Best regards, YC cmake --help-command set_property. It is a cmake command in the context you are using it. -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, master, updated. v2.8.10.2-554-gda2b024
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 da2b0245a380282892be8007f4c3d184a91bcfe0 (commit) via 7bf490e9bb6128082aa178f28691b3fc418322fe (commit) via f6b16d4b0642d26111cddff714b464e22b715482 (commit) via b3a7e19ee479fda18b1dfe237fc4b78467c05fd7 (commit) from 7462a8a8c3417e559e54d6de7eef837e2adfd2e6 (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=da2b0245a380282892be8007f4c3d184a91bcfe0 commit da2b0245a380282892be8007f4c3d184a91bcfe0 Merge: 7462a8a 7bf490e Author: Brad King brad.k...@kitware.com AuthorDate: Wed Jan 30 09:38:52 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Jan 30 09:38:52 2013 -0500 Merge topic 'fix-target-property-commands' 7bf490e Make subclasses responsible for joining content. f6b16d4 Don't allow targets args in the new target commands. b3a7e19 Make the Property name protected so that subclasses can use it. --- Summary of changes: Source/cmTargetCompileDefinitionsCommand.cxx | 31 ++ Source/cmTargetCompileDefinitionsCommand.h |9 +--- Source/cmTargetIncludeDirectoriesCommand.cxx | 44 --- Source/cmTargetIncludeDirectoriesCommand.h |9 +--- Source/cmTargetPropCommandBase.cxx | 33 +++ Source/cmTargetPropCommandBase.h | 19 - .../target_compile_definitions/CMakeLists.txt |3 +- .../target_compile_definitions/consumer.cpp|4 ++ .../target_include_directories/CMakeLists.txt |3 +- .../target_include_directories/consumer.cpp|5 ++ .../relative_dir/relative_dir.h|2 + Tests/ExportImport/Import/A/CMakeLists.txt | 19 ++--- 12 files changed, 98 insertions(+), 83 deletions(-) create mode 100644 Tests/CMakeCommands/target_include_directories/relative_dir/relative_dir.h hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1825-g9f22769
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 9f22769acc9ebdff3aa5ac3ccf53083dbd4d371d (commit) via da2b0245a380282892be8007f4c3d184a91bcfe0 (commit) via 7462a8a8c3417e559e54d6de7eef837e2adfd2e6 (commit) from 94a978d1b7ac9e85549e3142c6479dfdde35be78 (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=9f22769acc9ebdff3aa5ac3ccf53083dbd4d371d commit 9f22769acc9ebdff3aa5ac3ccf53083dbd4d371d Merge: 94a978d da2b024 Author: Brad King brad.k...@kitware.com AuthorDate: Wed Jan 30 09:39:18 2013 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Wed Jan 30 09:39:18 2013 -0500 Merge branch 'master' into next --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.10.2-555-gfc2638f
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 fc2638f0b43f88683b6d8251be92119f4a3b3f1b (commit) from da2b0245a380282892be8007f4c3d184a91bcfe0 (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=fc2638f0b43f88683b6d8251be92119f4a3b3f1b commit fc2638f0b43f88683b6d8251be92119f4a3b3f1b Author: Kitware Robot kwro...@kitware.com AuthorDate: Thu Jan 31 00:01:16 2013 -0500 Commit: Kitware Robot kwro...@kitware.com CommitDate: Thu Jan 31 00:01:16 2013 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 2010f63..7e9cc40 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ set(CMake_VERSION_MAJOR 2) set(CMake_VERSION_MINOR 8) set(CMake_VERSION_PATCH 10) -set(CMake_VERSION_TWEAK 20130130) +set(CMake_VERSION_TWEAK 20130131) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
