[cmake-developers] [CMake 0013986]: Target names may not contain a plus sign anymore
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=13986
==
Reported By:Benjamin Kloster
Assigned To:
==
Project:CMake
Issue ID: 13986
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2013-03-06 08:31 EST
Last Modified: 2013-03-06 08:31 EST
==
Summary:Target names may not contain a plus sign anymore
Description:
Since the latest revision in Git (commit efdf152), CMake balks at targets with a
plus sign in their name. Since it's a common practice to name C++ wrapper of
some libraries as MyLib++, that's a little strange. Attached is a diff that adds
the plus sign to the regex used to verify target names.
Steps to Reproduce:
Invoke CMake with a CMakeLists.txt containing:
add_executable(mylib++ ${SOURCE_FILES})
It will fail with the error message Target name not supported
Additional Information:
See also: http://www.mail-archive.com/cmake@cmake.org/msg45517.html
==
Issue History
Date ModifiedUsername FieldChange
==
2013-03-06 08:31 Benjamin KlosterNew Issue
2013-03-06 08:31 Benjamin KlosterFile Added: allow_plus_sign.diff
==
--
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] Preparing for 2.8.11-rc1
On Tuesday 05 March 2013, Stephen Kelly wrote: Alexander Neundorf wrote: did you get around to add handling for usr-move to the relative directory references for exports-files ? Otherwise I'll see whether I find time this week. I didn't work more on that, no, as I wrote here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5868/focu s=5985 Ok, I wasn't sure about this. I'll have a look at it in the next days. You may have already realised that, for the same reason, I didn't work more on this stuff either: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6106/focu s=6161 That branch was just a proof of concept. Oh, ok, here I assumed you would have finished it in the meantime. Can you try to get this in shape for 2.8.11 ? Alex -- 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] Preparing for 2.8.11-rc1
On Wednesday 06 March 2013, Brad King wrote: On 3/5/2013 5:05 PM, Stephen Kelly wrote: Stephen Kelly wrote: So, I think it's mature enough for release now, yes. It might be worth documenting it a bit more prominently though... Any opinion on this? I think the patch can be simpler: -through variables documented by the package itself. +through variables and imported targets documented by the package itself. IMO it is up to the package to advertise imported targets in its documentation. I think it's cool and a really good thing that imported targets can do more stuff now. It should also be documented well so that people are aware that the results if find_package(SomePackage) or no longer necessarily only file paths and directories, but also imported targets. But I think it's a step backward to use imported target names directly. One thing cmake users do complain about regularly is that they can't rely on what the names of the variables defined after find_package(SomePackage) are, even though there are guidelines for the naming in readme.txt. The results may be SOMEPACKAGE_LIBS, SOMEPACKAGE_LIBRARY, SOMEPACKAGE_LIBRARIES, SomePackage_LIBS, SomePackage_LIBRARY, SomePackage_LIBRARIES This is the one single strongest complaint I hear about using find_package(). We should try to fix this complaint by making the Find-modules/Config-files comply as good as possible to readme.txt, which we agreed upon that the correct name would be SomePackage_LIBRARIES. If we concentrate on that, using find_package() will become easier, since the variables will follow the standard naming. If we reach this, we'll have real progress, and we'll have made cmake really easier to use. If we now instead of following that strategy, start to recommend that packages may also document their exported/imported targets, we go in the opposite direction. When doing find_package(SomePackage) the user now again will have to read the documentation, just to find out whether he should use SomePackage_LIBRARIES or the imported target somepackagelib directly. So there would be two competing standards then ;-) Additionally, currently there are no guidelines for how exported/imported targets should be named, so besides having to find out whether targets should be used directly, they would have to read the documentation to find out how those targets are named. If we recommend using imported target names directory, readme.txt should contain guidelines for how to name the targets and namespaces. Also, using imported target names directly removes the isolation layer between in-project developers and how they name their targets, and users of their projects, which is by now provided by the variables set in Find- modules/Config-files. Another idea would by to have a new, additional standard variable SomePackage_TARGET or something like this. This would keep the advantage of the isolation layer, and the advantage of the standard naming, it would also make it visible that the thing is a target and may have include dirs attached, the downside would still be that the user has to find out whether he is supposed to use SomePackage_TARGET or SomePackage_LIBRARIES. Alex -- 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] Preparing for 2.8.11-rc1
Stephen Kelly wrote: https://gitorious.org/~steveire/cmake/steveires-cmake/commit/96ec58003de583 794fb7440fc4b3521f272a26d6 in, but then again, the behavior of code like that won't change until the next release, and a policy will probably be needed anyway. So you introduce new stuff now and intend to change the way it works in the next release? Or you intend to change the way old stuff works in next release? Eike -- signature.asc Description: This is a digitally signed message part. -- 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-developers] [CMake 0013988]: Ninja: generated files like moc, huge deps list (bis)
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13988 == Reported By:bamiaux Assigned To: == Project:CMake Issue ID: 13988 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2013-03-06 17:59 EST Last Modified: 2013-03-06 17:59 EST == Summary:Ninja: generated files like moc, huge deps list (bis) Description: I believe the bug http://www.cmake.org/Bug/view.php?id=13874 is still present. Compiling the included project mandelbrot with the nightly build taken at http://www.cmake.org/files/dev/cmake-2.8.10.20130305-gd559be-win32-x86.zip still have cpp files which depend on every generated moc file. This is the same behavior I get in my own project. This is not restricted to moc files, actually all generated files get put as dependency to every cpp leading to very huge ninja dependencies. This bug is supposed to have been fixed by the following commit http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bbea30eec88fe6dc98d716f16141c6aab6a75314 == Issue History Date ModifiedUsername FieldChange == 2013-03-06 17:59 bamiauxNew Issue == -- 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] Preparing for 2.8.11-rc1
Alexander Neundorf wrote: You may have already realised that, for the same reason, I didn't work more on this stuff either: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6106/focu s=6161 That branch was just a proof of concept. Oh, ok, here I assumed you would have finished it in the meantime. Can you try to get this in shape for 2.8.11 ? No, I'm afraid not. I'm not certain the approach I took was the correct one, and I'm not taking over responsibility for the feature completely in general. My patch would cause a fatal_error if an imported target (either generated or hand-written) has a target in its link interface which does not exist (even if it is not used). From my reading of what Brad wrote, that's plausible: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6106/focus=6138 also, as the ImportInfo is retrieved when exporting targets, you may need to consider whether that can/should raise a fatal_error too. So, I think there's more work to do on that feature on several levels, and in the interest of being clear :), I'm not taking over responsibility for that work, though I'll help with code snippets as I did before. 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
[CMake] how to compile as 64bit on win
I'm using a current developers snapshot of cmake to include the fix of
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=add8d22acc9417cb144a0b497f4f5ef330bfc680
However, a simple cmake file
project(test)
message(${CMAKE_SYSTEM_PROCESSOR})
always gives me x86.
This is on a win8 machine and cmake run inside a shell with the title
Visual Studio x64 Win64 Command Prompt (2010)
Calling cl in this shell gives ... for x64 and checking the PATH env var
also shows that the first path is ...Visual Studio 10.0\VC\BIN\amd64;...
So ... what am I doing wrong ?
In cmake 2.8.10.2 I could use -G Visual Studio 10 Win64 which is no longer an
option with the current cmake snapshot. With what exactly was it replaced ?
(I found the new option -T but without any useful documentation)
Also, how would I run cmake and creating a jom based builddir for 64bit ?
There was never an option jom 64 or something ...
--
Best regards/Schöne Grüße
Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
This mail was not scanned before sending.
It was sent from a secure Linux desktop.
--
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] CPack source packaging
Dear list members, I made a project with CMake (2.8.10) on Linux and want to use CPack to create its source .tar.bz2 file. The task is really simple: copy all of the *.cpp and *.h files into the .tar.bz2 file preserving the directory structure. Although sounds really simple, I've yet to find a solution. The problems are: - In the source directory goes the development also, producing a lot of other files which are unneeded. - With CPACK_SOURCE_IGNORE_FILES variable I can exclude some files, but without the regexp positive lookahead feature I cannot say exclude everything, except for the *.cpp and *.h - Other solution would be an external command (eg. find and cp) to copy all the files into an other temporary directory and set that directory as the source directory. The drawback: there's no way to tell in CMakeLists.txt which is the current CPack generator, so I simply can't write if (CPACK_GENERATOR STREQUAL TBZ2), because CPACK_GENERATOR is empty at cmake . time. So the find and copy command either ran all the time or not even once. - As a last resort I can execute a bz2 command which would do all the necessary things, but that would run every time (see the problem above). The command I issue to generate the source: cpack --config CPackSourceConfig.cmake Is there a simple solution to achieve this? Best regards, Ákos Szőts -- 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] how to compile as 64bit on win
On Wednesday 06 March 2013 09:57:09 Koller, Martin wrote:
I'm using a current developers snapshot of cmake to include the fix of
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=add8d22acc9417cb144a0b497f4f5ef330bfc680
However, a simple cmake file
project(test)
message(${CMAKE_SYSTEM_PROCESSOR})
always gives me x86.
I think the obove commit is wrong.
The check seems wrong:
if (ENV{PROCESSOR_ARCHITEW6432})
I see no documentation where I could use this ENV{...} syntax.
I only find $ENV{}
But probably it's just not documented.
However, I locally modified the if to
if (DEFINED ENV{PROCESSOR_ARCHITEW6432})
and now it works.
--
Best regards/Schöne Grüße
Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
This mail was not scanned before sending.
It was sent from a secure Linux desktop.
--
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] Target name not (any longer) supported
Testing the current cmake snapshot (on win8, VS 2010) shows error messages
which I did not have with the latest released cmake version:
CMake Error:
Error evaluating generator expression:
$TARGET_PROPERTY:agent++,INTERFACE_COMPILE_DEFINITIONS
Target name not supported.
The target is defined as
add_library(agent++ STATIC ${SOURCES})
Is this an intentional change for the next cmake version or is it a bug I
should report in mantis ?
--
Best regards/Schöne Grüße
Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
This mail was not scanned before sending.
It was sent from a secure Linux desktop.
--
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] Check for working C compiler using: Visual Studio 10 -- broken
On 5 March 2013 17:09, Bill Hoffman bill.hoff...@kitware.com wrote: On 3/5/2013 11:40 AM, Mateusz Loskot wrote: Nice tip with the solution in the CMakeTmp, I had no idea about it. I figured out that the VS2010 project there, cmTryCompileExec3417082516.vcxproj, specifies for linker /INCREMENTAL:YES If I change to /INCREMENTAL:NO, then it builds. Still not sure how the VS2010/VS2012 toolsets interfere here, but it looks like this mess is not related to any problems with CMake. Seems to match what is in that stackoverflow article. Yes, I have made a circle and came back to that solution. Taking off incremental seemed to fix the problem for them as well. If you read that thread close, there seems to be ways to fix the problem... Installing VS2010 SP1 as the only sensible option. Thanks! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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 source packaging
2013/3/6 Szőts Ákos szots...@gmail.com: Dear list members, I made a project with CMake (2.8.10) on Linux and want to use CPack to create its source .tar.bz2 file. The task is really simple: copy all of the *.cpp and *.h files into the .tar.bz2 file preserving the directory structure. Although sounds really simple, I've yet to find a solution. The problems are: - In the source directory goes the development also, producing a lot of other files which are unneeded. If you say so, may be you are building in-source. Did you try out-of-source build? http://www.cmake.org/Wiki/CMake_FAQ#Out-of-source_build_trees If you are already doing out-of-source build and want to exclude some other files then CPACK_SOURCE_IGNORE_FILES should be the way to go. - With CPACK_SOURCE_IGNORE_FILES variable I can exclude some files, but without the regexp positive lookahead feature I cannot say exclude everything, except for the *.cpp and *.h Yes, unfortunately there is no CPACK_SOURCE_INCLUDE_FILES. - Other solution would be an external command (eg. find and cp) to copy all the files into an other temporary directory and set that directory as the source directory. The drawback: there's no way to tell in CMakeLists.txt which is the current CPack generator, so I simply can't write if (CPACK_GENERATOR STREQUAL TBZ2), because CPACK_GENERATOR is empty at cmake . time. So the find and copy command either ran all the time or not even once. You'll have to implement CPack time copy, you may do that inside a CPACK_PROJECT_CONFIG_FILE. see: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overall_usage_.28common_to_all_generators.29 However I don't think it's the best solution in your case. - As a last resort I can execute a bz2 command which would do all the necessary things, but that would run every time (see the problem above). The command I issue to generate the source: cpack --config CPackSourceConfig.cmake Is there a simple solution to achieve this? Like I said, out-of-source, should be the easy way to achieve what you want. Another way to have a clean copy would be to use your VCS e.g. svn export + tar/zip/ in a custom_command cvs export + tar/zip/ in a custom_command git archive ... see: http://stackoverflow.com/questions/160608/how-to-do-a-git-export-like-svn-export -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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] Target name not (any longer) supported
Same here with a target named gdcp++. Seems to be a problem with the
plus sign.
On 03/06/2013 10:55 AM, Martin Koller wrote:
Testing the current cmake snapshot (on win8, VS 2010) shows error messages
which I did not have with the latest released cmake version:
CMake Error:
Error evaluating generator expression:
$TARGET_PROPERTY:agent++,INTERFACE_COMPILE_DEFINITIONS
Target name not supported.
The target is defined as
add_library(agent++ STATIC ${SOURCES})
Is this an intentional change for the next cmake version or is it a bug I
should report in mantis ?
--
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] Target name not (any longer) supported
Title: Vorlage VIDELCO Europe Limited
I've created an issue in the bug
tracker
http://www.cmake.org/Bug/view.php?id=13986
with an attached diff to re-allow plus signs.
On 03/06/2013 01:48 PM, Benjamin Kloster wrote:
Same here with a target named
"gdcp++". Seems to be a problem with the plus sign.
On 03/06/2013 10:55 AM, Martin Koller wrote:
Testing the current cmake snapshot (on win8, VS 2010) shows error messages
which I did not have with the latest released cmake version:
CMake Error:
Error evaluating generator _expression_:
$TARGET_PROPERTY:agent++,INTERFACE_COMPILE_DEFINITIONS
Target name not supported.
The target is defined as
add_library(agent++ STATIC ${SOURCES})
Is this an intentional change for the next cmake version or is it a bug I
should report in mantis ?
--
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
--
___
VIDELCO Europe Limited
Selbststndige Zweigniederlassung:
Lise-Meitner-Str. 6
D-40878 Ratingen
Fon: +49 (0) 21 02 / 86 39-00
Fax: +49 (0) 21 02 / 86 39-17
E-Mail: benjamin.klos...@videlco.eu
Internet: http://www.videlco.eu
Geschftsfhrer:
Wolfgang Waldeyer, Mike Waldeyer
HRB Dsseldorf 54534
USt-Id-Nr.: DE814733639
--
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] how to compile as 64bit on win
Martin Koller wrote:
On Wednesday 06 March 2013 09:57:09 Koller, Martin wrote:
I'm using a current developers snapshot of cmake to include the fix of
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=add8d22acc9417cb144a0b4
97f4f5ef330bfc680
However, a simple cmake file
project(test)
message(${CMAKE_SYSTEM_PROCESSOR})
always gives me x86.
I think the obove commit is wrong.
The check seems wrong:
if (ENV{PROCESSOR_ARCHITEW6432})
I see no documentation where I could use this ENV{...} syntax.
I only find $ENV{}
But probably it's just not documented.
However, I locally modified the if to
if (DEFINED ENV{PROCESSOR_ARCHITEW6432})
and now it works.
Thanks for testing. Fix pushed to next branch:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=20681c9e0573fcc7f1a9870c54a4edd5fde14568
Eike
--
signature.asc
Description: This is a digitally signed message part.
--
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, next, updated. v2.8.10.2-2396-gcab81f2
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 cab81f23cb59bd5cbd50970a91d42f4a465a79e6 (commit) via eed2637e99955c8c762ad1deea65877c43bd1a22 (commit) via 254687d31f2f45b0d3ce9085c013ab0e15b360de (commit) via efdf152fe1582be3e39f3a16e0ddaeb386fe1c20 (commit) from d559bec27163c17935eb2cbeab0e41cf0e8fbdc5 (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=cab81f23cb59bd5cbd50970a91d42f4a465a79e6 commit cab81f23cb59bd5cbd50970a91d42f4a465a79e6 Merge: d559bec eed2637 Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed Mar 6 11:46:39 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Mar 6 11:46:39 2013 -0500 Merge topic 'fix-transitive-target-names' into next eed2637 Extend the range of valid target names with the + sign. 254687d Only process transitive interface properties for valid target names. efdf152 CMake Nightly Date Stamp http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eed2637e99955c8c762ad1deea65877c43bd1a22 commit eed2637e99955c8c762ad1deea65877c43bd1a22 Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed Mar 6 17:26:40 2013 +0100 Commit: Stephen Kelly steve...@gmail.com CommitDate: Wed Mar 6 17:43:23 2013 +0100 Extend the range of valid target names with the + sign. As noted in #13986, this character can commonly be used for target names, such as those containing 'c++'. Suggested-By: Benjamin Kloster diff --git a/Source/cmGeneratorExpression.cxx b/Source/cmGeneratorExpression.cxx index 7ea58fa..3f59129 100644 --- a/Source/cmGeneratorExpression.cxx +++ b/Source/cmGeneratorExpression.cxx @@ -393,7 +393,7 @@ bool cmGeneratorExpression::IsValidTargetName(const std::string input) cmsys::RegularExpression targetNameValidator; // The ':' is supported to allow use with IMPORTED targets. At least // Qt 4 and 5 IMPORTED targets use ':' as the namespace delimiter. - targetNameValidator.compile(^[A-Za-z0-9_.:-]+$); + targetNameValidator.compile(^[A-Za-z0-9_.:+-]+$); return targetNameValidator.find(input.c_str()); } diff --git a/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt b/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt index b13c13d..e4cb217 100644 --- a/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt +++ b/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt @@ -102,7 +102,11 @@ target_compile_definitions(depG INTERFACE TEST_DEF ) +# Linking to a target containing a + should be non-fatal. +add_library(wrapc++ empty.cpp) + add_executable(targetC targetC.cpp) +target_link_libraries(targetC wrapc++) # The TARGET_PROPERTY expression is duplicated below to test that there is no # shortcutting of the evaluation by returning an empty string. set(_exe_test $STREQUAL:$TARGET_PROPERTY:TYPE,EXECUTABLE) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=254687d31f2f45b0d3ce9085c013ab0e15b360de commit 254687d31f2f45b0d3ce9085c013ab0e15b360de Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed Mar 6 17:15:57 2013 +0100 Commit: Stephen Kelly steve...@gmail.com CommitDate: Wed Mar 6 17:42:08 2013 +0100 Only process transitive interface properties for valid target names. Commit a1c4905f (Use the link information as a source of compile definitions and includes., 2013-02-12) introduced the use of link information as the source of target properties via the TARGET_PROPERTY generator expression. This generator expression has a strict interpretation of a valid target name and emits a fatal error for invalid names. Ensure that only targets with names valid for use with TARGET_PROPERTY or targets which are determined by generator expressions are processed by it. This means that at worst, invalid target names do not participate in the transitive evaluation of properties, but the validation generator expression can be extended where needed to resolve that. diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx index f38b16e..d46325b 100644 --- a/Source/cmTarget.cxx +++ b/Source/cmTarget.cxx @@ -2898,7 +2898,8 @@ std::vectorstd::string cmTarget::GetIncludeDirectories(const char *config) ge.Parse(it-Value); std::string result = cge-Evaluate(this-Makefile, config, false, this, 0, 0); - if (!this-Makefile-FindTargetToUse(result.c_str())) + if (!cmGeneratorExpression::IsValidTargetName(result.c_str()) + || !this-Makefile-FindTargetToUse(result.c_str()))
[Cmake-commits] CMake branch, next, updated. v2.8.10.2-2398-g5bc2cc7
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 5bc2cc79977e38bd639dd300f1f2ea67bced4de7 (commit) via 192228225995366728ea9f94f35a070636c7b1f0 (commit) from cab81f23cb59bd5cbd50970a91d42f4a465a79e6 (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=5bc2cc79977e38bd639dd300f1f2ea67bced4de7 commit 5bc2cc79977e38bd639dd300f1f2ea67bced4de7 Merge: cab81f2 1922282 Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed Mar 6 11:50:52 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Mar 6 11:50:52 2013 -0500 Merge topic 'update-find_package-docs' into next 1922282 Mention that IMPORTED targets may be created by a find_package call. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=192228225995366728ea9f94f35a070636c7b1f0 commit 192228225995366728ea9f94f35a070636c7b1f0 Author: Stephen Kelly steve...@gmail.com AuthorDate: Tue Mar 5 23:01:22 2013 +0100 Commit: Stephen Kelly steve...@gmail.com CommitDate: Wed Mar 6 17:50:20 2013 +0100 Mention that IMPORTED targets may be created by a find_package call. diff --git a/Source/cmFindPackageCommand.cxx b/Source/cmFindPackageCommand.cxx index 470ceca..0122dc1 100644 --- a/Source/cmFindPackageCommand.cxx +++ b/Source/cmFindPackageCommand.cxx @@ -95,7 +95,8 @@ void cmFindPackageCommand::GenerateDocumentation() Finds and loads settings from an external project. package_FOUND will be set to indicate whether the package was found. When the package is found package-specific information is provided -through variables documented by the package itself. +through variables and imported targets documented by the package +itself. The QUIET option disables messages if the package cannot be found. The MODULE option disables the second signature documented below. The REQUIRED option stops processing with an error message if the --- Summary of changes: Source/cmFindPackageCommand.cxx |3 ++- 1 files changed, 2 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, next, updated. v2.8.10.2-2400-gff923e5
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 ff923e5b7ab8aabdf2e84efd8942e566d6a946a2 (commit)
via a85ddd7bf0f266fda093b5b3b05e384bd8189af5 (commit)
from 5bc2cc79977e38bd639dd300f1f2ea67bced4de7 (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=ff923e5b7ab8aabdf2e84efd8942e566d6a946a2
commit ff923e5b7ab8aabdf2e84efd8942e566d6a946a2
Merge: 5bc2cc7 a85ddd7
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Mar 6 11:56:23 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Mar 6 11:56:23 2013 -0500
Merge topic 'fix-transitive-target-names' into next
a85ddd7 Add missing file.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a85ddd7bf0f266fda093b5b3b05e384bd8189af5
commit a85ddd7bf0f266fda093b5b3b05e384bd8189af5
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Mar 6 17:54:50 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Mar 6 17:54:50 2013 +0100
Add missing file.
diff --git a/Tests/CMakeCommands/target_link_libraries/empty.cpp
b/Tests/CMakeCommands/target_link_libraries/empty.cpp
new file mode 100644
index 000..ab32cf6
--- /dev/null
+++ b/Tests/CMakeCommands/target_link_libraries/empty.cpp
@@ -0,0 +1 @@
+// No content
---
Summary of changes:
.../target_link_libraries}/empty.cpp |0
1 files changed, 0 insertions(+), 0 deletions(-)
copy Tests/{QtAutomoc = CMakeCommands/target_link_libraries}/empty.cpp (100%)
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-2404-g2a21835
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 2a21835ddf6878d001b36ebb6e3edcdee92af380 (commit)
via 20681c9e0573fcc7f1a9870c54a4edd5fde14568 (commit)
from 32c56747a95cb291064cd0f1ec392467651de19d (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=2a21835ddf6878d001b36ebb6e3edcdee92af380
commit 2a21835ddf6878d001b36ebb6e3edcdee92af380
Merge: 32c5674 20681c9
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Wed Mar 6 12:05:30 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Mar 6 12:05:30 2013 -0500
Merge topic 'Win-HOST_SYSTEM_PROCESSOR' into next
20681c9 fix Windows processor detection
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=20681c9e0573fcc7f1a9870c54a4edd5fde14568
commit 20681c9e0573fcc7f1a9870c54a4edd5fde14568
Author: Rolf Eike Beer e...@sf-mail.de
AuthorDate: Wed Mar 6 18:04:53 2013 +0100
Commit: Rolf Eike Beer e...@sf-mail.de
CommitDate: Wed Mar 6 18:04:53 2013 +0100
fix Windows processor detection
Thanks to Martin Koller for this.
diff --git a/Modules/CMakeDetermineSystem.cmake
b/Modules/CMakeDetermineSystem.cmake
index 20c1541..3a95d2a 100644
--- a/Modules/CMakeDetermineSystem.cmake
+++ b/Modules/CMakeDetermineSystem.cmake
@@ -73,7 +73,7 @@ if(CMAKE_HOST_UNIX)
else()
if(CMAKE_HOST_WIN32)
set (CMAKE_HOST_SYSTEM_NAME Windows)
-if (ENV{PROCESSOR_ARCHITEW6432})
+if (DEFINED ENV{PROCESSOR_ARCHITEW6432})
set (CMAKE_HOST_SYSTEM_PROCESSOR $ENV{PROCESSOR_ARCHITEW6432})
else()
set (CMAKE_HOST_SYSTEM_PROCESSOR $ENV{PROCESSOR_ARCHITECTURE})
---
Summary of changes:
Modules/CMakeDetermineSystem.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, next, updated. v2.8.10.2-2406-g8eefc48
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 8eefc48a4659cc3b4d341990693a01dd77974863 (commit) via 8cdb81f3c17490aee16acbb656f388bb0d7deddb (commit) from 2a21835ddf6878d001b36ebb6e3edcdee92af380 (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=8eefc48a4659cc3b4d341990693a01dd77974863 commit 8eefc48a4659cc3b4d341990693a01dd77974863 Merge: 2a21835 8cdb81f Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed Mar 6 15:34:55 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Mar 6 15:34:55 2013 -0500 Merge topic 'update-find_package-docs' into next 8cdb81f Fix whitespace. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8cdb81f3c17490aee16acbb656f388bb0d7deddb commit 8cdb81f3c17490aee16acbb656f388bb0d7deddb Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed Mar 6 21:32:29 2013 +0100 Commit: Stephen Kelly steve...@gmail.com CommitDate: Wed Mar 6 21:32:29 2013 +0100 Fix whitespace. diff --git a/Source/cmFindPackageCommand.cxx b/Source/cmFindPackageCommand.cxx index 0122dc1..aa3a73d 100644 --- a/Source/cmFindPackageCommand.cxx +++ b/Source/cmFindPackageCommand.cxx @@ -95,7 +95,7 @@ void cmFindPackageCommand::GenerateDocumentation() Finds and loads settings from an external project. package_FOUND will be set to indicate whether the package was found. When the package is found package-specific information is provided -through variables and imported targets documented by the package +through variables and imported targets documented by the package itself. The QUIET option disables messages if the package cannot be found. The MODULE option disables the second signature documented below. --- Summary of changes: Source/cmFindPackageCommand.cxx |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, next, updated. v2.8.10.2-2408-g1fa6f91
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 1fa6f9172ebb8db4c8a4f2d2b63aa91ae5d37b50 (commit) via b73e05d7c993854721a5798f852d6afb726a (commit) from 8eefc48a4659cc3b4d341990693a01dd77974863 (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=1fa6f9172ebb8db4c8a4f2d2b63aa91ae5d37b50 commit 1fa6f9172ebb8db4c8a4f2d2b63aa91ae5d37b50 Merge: 8eefc48 b73e05d Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed Mar 6 15:35:49 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Mar 6 15:35:49 2013 -0500 Merge topic 'update-find_package-docs' into next b73e05d Mention that IMPORTED targets may be created by a find_package call. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b73e05d7c993854721a5798f852d6afb726a commit b73e05d7c993854721a5798f852d6afb726a Author: Stephen Kelly steve...@gmail.com AuthorDate: Tue Mar 5 23:01:22 2013 +0100 Commit: Stephen Kelly steve...@gmail.com CommitDate: Wed Mar 6 21:35:20 2013 +0100 Mention that IMPORTED targets may be created by a find_package call. diff --git a/Source/cmFindPackageCommand.cxx b/Source/cmFindPackageCommand.cxx index 470ceca..aa3a73d 100644 --- a/Source/cmFindPackageCommand.cxx +++ b/Source/cmFindPackageCommand.cxx @@ -95,7 +95,8 @@ void cmFindPackageCommand::GenerateDocumentation() Finds and loads settings from an external project. package_FOUND will be set to indicate whether the package was found. When the package is found package-specific information is provided -through variables documented by the package itself. +through variables and imported targets documented by the package +itself. The QUIET option disables messages if the package cannot be found. The MODULE option disables the second signature documented below. The REQUIRED option stops processing with an error message if the --- Summary of changes: 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-2410-g98bc278
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 98bc278ef6ef299980e46f21a2b916b7b10793e4 (commit) via 531067f69ef8d9e9b49a64a7ddc2bf9baeaa2c54 (commit) from 1fa6f9172ebb8db4c8a4f2d2b63aa91ae5d37b50 (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=98bc278ef6ef299980e46f21a2b916b7b10793e4 commit 98bc278ef6ef299980e46f21a2b916b7b10793e4 Merge: 1fa6f91 531067f Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed Mar 6 16:52:56 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Mar 6 16:52:56 2013 -0500 Merge topic 'fix-transitive-target-names' into next 531067f Don't test + in target names on Borland. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=531067f69ef8d9e9b49a64a7ddc2bf9baeaa2c54 commit 531067f69ef8d9e9b49a64a7ddc2bf9baeaa2c54 Author: Stephen Kelly steve...@gmail.com AuthorDate: Wed Mar 6 22:51:39 2013 +0100 Commit: Stephen Kelly steve...@gmail.com CommitDate: Wed Mar 6 22:51:39 2013 +0100 Don't test + in target names on Borland. It fails with such target names as it strips the '+': Fatal: Unable to open file 'WRAPC.LIB' http://open.cdash.org/testDetails.php?test=179971699build=2837755 diff --git a/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt b/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt index e4cb217..0309e1d 100644 --- a/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt +++ b/Tests/CMakeCommands/target_link_libraries/CMakeLists.txt @@ -102,11 +102,14 @@ target_compile_definitions(depG INTERFACE TEST_DEF ) -# Linking to a target containing a + should be non-fatal. -add_library(wrapc++ empty.cpp) add_executable(targetC targetC.cpp) -target_link_libraries(targetC wrapc++) +if(NOT BORLAND) + # Linking to a target containing a + should be non-fatal, though it does + # not work at all on Borland + add_library(wrapc++ empty.cpp) + target_link_libraries(targetC wrapc++) +endif() # The TARGET_PROPERTY expression is duplicated below to test that there is no # shortcutting of the evaluation by returning an empty string. set(_exe_test $STREQUAL:$TARGET_PROPERTY:TYPE,EXECUTABLE) --- Summary of changes: .../target_link_libraries/CMakeLists.txt |9 ++--- 1 files changed, 6 insertions(+), 3 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, next, updated. v2.8.10.2-2412-g13904cf
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 13904cf9790feea6c8566f85bf2965d0768c588d (commit)
via adcc00b16a24d66f7cab5336f31b14a32d3240a7 (commit)
from 98bc278ef6ef299980e46f21a2b916b7b10793e4 (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=13904cf9790feea6c8566f85bf2965d0768c588d
commit 13904cf9790feea6c8566f85bf2965d0768c588d
Merge: 98bc278 adcc00b
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Mar 6 16:55:57 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Mar 6 16:55:57 2013 -0500
Merge topic 'clean-target_link_libraries-test' into next
adcc00b Remove unused parameters from target_link_libraries tests.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=adcc00b16a24d66f7cab5336f31b14a32d3240a7
commit adcc00b16a24d66f7cab5336f31b14a32d3240a7
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Mar 6 22:54:49 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Mar 6 22:54:49 2013 +0100
Remove unused parameters from target_link_libraries tests.
diff --git a/Tests/CMakeCommands/target_link_libraries/targetA.cpp
b/Tests/CMakeCommands/target_link_libraries/targetA.cpp
index 559aef7..d1321a1 100644
--- a/Tests/CMakeCommands/target_link_libraries/targetA.cpp
+++ b/Tests/CMakeCommands/target_link_libraries/targetA.cpp
@@ -5,7 +5,7 @@
#include subdirlib.h
-int main(int argc, char **argv)
+int main(int, char **)
{
DepA a;
DepB b;
diff --git a/Tests/CMakeCommands/target_link_libraries/targetB.cpp
b/Tests/CMakeCommands/target_link_libraries/targetB.cpp
index 063d63a..0913a57 100644
--- a/Tests/CMakeCommands/target_link_libraries/targetB.cpp
+++ b/Tests/CMakeCommands/target_link_libraries/targetB.cpp
@@ -1,7 +1,7 @@
#include depD.h
-int main(int argc, char **argv)
+int main(int, char **)
{
DepD d;
DepA a = d.getA();
diff --git a/Tests/CMakeCommands/target_link_libraries/targetC.cpp
b/Tests/CMakeCommands/target_link_libraries/targetC.cpp
index ff6ba66..a4ef636 100644
--- a/Tests/CMakeCommands/target_link_libraries/targetC.cpp
+++ b/Tests/CMakeCommands/target_link_libraries/targetC.cpp
@@ -8,7 +8,7 @@
#error Expected TEST_DEF definition
#endif
-int main(int argc, char **argv)
+int main(int, char **)
{
DepG g;
---
Summary of changes:
.../target_link_libraries/targetA.cpp |2 +-
.../target_link_libraries/targetB.cpp |2 +-
.../target_link_libraries/targetC.cpp |2 +-
3 files changed, 3 insertions(+), 3 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-816-g06a45e8
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 06a45e816958065849c30dd3029db538aa7b399e (commit) from efdf152fe1582be3e39f3a16e0ddaeb386fe1c20 (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=06a45e816958065849c30dd3029db538aa7b399e commit 06a45e816958065849c30dd3029db538aa7b399e Author: Kitware Robot kwro...@kitware.com AuthorDate: Thu Mar 7 00:01:10 2013 -0500 Commit: Kitware Robot kwro...@kitware.com CommitDate: Thu Mar 7 00:01:10 2013 -0500 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index d20ec62..a42e5b6 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 20130306) +set(CMake_VERSION_TWEAK 20130307) #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
