[cmake-developers] FindPkgConfig and CMAKE_PREFIX_PATH
Hello all,
FindPkgConfig does not support the CMAKE_PREFIX_PATH variable.
This is because pkg-config uses the PKG_CONFIG_PATH and does not know
anything
about CMAKE_PREFIX_PATH.
As a consequence, pkg-config packages built and installed in a non standard
directory using ExternalProject, cannot be found, while cmake ones can
be easily
located setting the CMAKE_PREFIX_PATH variable.
Do you think it could make sense to add to FindPkgConfig something like
this?
set(_pkgconfig_path $ENV{PKG_CONFIG_PATH})
foreach(_dir ${CMAKE_PREFIX_PATH})
set(ENV{PKG_CONFIG_PATH} $ENV{PKG_CONFIG_PATH}:${_dir}/lib/pkgconfig)
endforeach()
[...] (search for package)
set(ENV{PKG_CONFIG_PATH} ${_pkgconfig_path})
Cheers,
Daniele
--
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] C++11 and target_compiler_feature proposal
Brad King wrote:
On 10/21/2013 04:05 PM, Stephen Kelly wrote:
I'm still not sure that generating a header specific to the compiler (ID
and version) is a good idea.
[snip]
So, I think maybe it would make sense to list features separately, and if
someone does this:
I thought we had reached that conclusion before. See the bottom of
this message:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7809
Anyway, we agree.
Further-on, you responded:
Why do you need to check features of a compiler not currently enabled?
write_compiler_detection_header(
FILE ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_detection.h
PREFIX Grantlee_
FEATURES cxx_final cxx_override
)
Yes, though it still needs the mandatory VERSION.
I thought the VERSION would be optional and would default to
CMAKE_MINIMUM_REQUIRED_VERSION:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7812
the generated header would look something like this:
Yes.
Actually it appears this header will duplicate most of the compiler
feature
knowledge encoded in the CMake platform modules we discussed before. I
wonder if we can come up with a representation that can be used to
generate both.
Probably. However, that means that we either shouldn't use the clang
__has_feature() test that I implemented, or we'll have to duplicate all of
that information anyway.
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] C++11 and target_compiler_feature proposal
On 10/22/2013 11:31 AM, Stephen Kelly wrote: Further-on, you responded: Why do you need to check features of a compiler not currently enabled? That was talking about the platform file tables, not the header. I thought the VERSION would be optional and would default to CMAKE_MINIMUM_REQUIRED_VERSION: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6726/focus=7812 Yes, okay. Actually it appears this header will duplicate most of the compiler feature knowledge encoded in the CMake platform modules we discussed before. I wonder if we can come up with a representation that can be used to generate both. Probably. However, that means that we either shouldn't use the clang __has_feature() test that I implemented, or we'll have to duplicate all of that information anyway. CMAKE_CXX_COMPILER is always set to the proper full path these days, even in the IDE generators, so I wonder if we could actually run it against the header file to detect the features available for the current compiler instead of hard-coding a table in the platform information files. Then the checks would all be done in one place via the preprocessor and __has_feature if available. -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] C++11 and target_compiler_feature proposal
On 10/22/2013 12:27 PM, Stephen Kelly wrote: Stephen Kelly wrote: I'll try to get a reviewable and first-feature-complete infrastructure branch together soon. Meanwhile, I've been continuing work on the target_compiler_features topic, which is for REQUIRED features. It's mostly feature complete now, but with a few things missing like adding -std flags for the correct compiler versions. It includes transitive requirement of compiler features, and a generator expression for testing whether a target has enabled the feature. It's also missing some unit tests etc. As this is orthogonal to an compilerdetection.h header, which is for optional features, I think I can polish this up and get it master soonish. Any comments? See my sibling response about implementing required feature lookup using the header. Otherwise, I'd like Eike to review your topic too. -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-developers] [CMake 0014504]: libarchive supports 7-Zip, Add 7-Zip support to cmake
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14504 == Reported By:Aaron Nowack Assigned To: == Project:CMake Issue ID: 14504 Category: CMake Reproducibility:have not tried Severity: feature Priority: low Status: new == Date Submitted: 2013-10-22 14:46 EDT Last Modified: 2013-10-22 14:46 EDT == Summary:libarchive supports 7-Zip, Add 7-Zip support to cmake Description: As I understand cmake uses libarchive for inflating tar.gz files. This is useful within ExternalProject_Add as you can pass in a URL of a tar.gz and cmake handles it. Since libarchive _also_ supports inflating 7z formats can cmake also support it? For example, I wanted to use ExternalProject_Add with a custom build install step to setup the libusbx binaries [1] on windows but they are in 7z format. [1] http://sourceforge.net/projects/libusbx/files/releases/1.0.17/binaries/ Steps to Reproduce: ExternalProject_Add( URL path to 7z archive ... ) Is not supported Additional Information: libarchive supports 7-zip , https://github.com/libarchive/libarchive == Issue History Date ModifiedUsername FieldChange == 2013-10-22 14:46 Aaron Nowack New 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] Perforce Patch for CTest
On 10/22/2013 02:51 PM, Pedro Navarro wrote:
get_filename_component(TOP ${CMAKE_CURRENT_LIST_FILE} PATH) could be
written
as CMAKE_CURRENT_LIST_DIR. I don't remember exactly when it was introduced,
but you drive that test with the newly built CMake so this must work. And a
newline is missing at the end of that file.
Would that be preferred? I have no issues using it but that's what the other
tests were using, so I wanted them to be as similar as possible.
Yes. The other tests' code predates CMAKE_CURRENT_LIST_DIR.
I would accept the patch for the new test either way though.
Thanks,
-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] Perforce Patch for CTest
Am Dienstag, 22. Oktober 2013, 11:51:52 schrieb Pedro Navarro: I would extend the regex in the DiffParser constructor to contain - at the end to make the propability that a filename with # in it would cause issues smaller. Also I find the usage of both Options and options in SetP4Options() an invitation for confusion (and possible errors). I'll change the regex. Although I verified it in debuggex to make sure we could correctly handle different combination of files with # and other characters in it, it makes sense to add the additional check. About the options, do you mean not using P4Options when doing an update if options for the update commands are given? I have to admit that I don't fully understand the difference between Update Options and VCS Specific options (I got that code from the GIT implementation) but Perforce has the notion of global and command specific flags. In this case, the global flags are the P4Options which are used to specify how do you connect to the server (host, port, username) and which client view to use, the other options are the flags you pass for the update command, which are completely different. I agree it can be confusing I meant that you have one variable called Options and one called options. This is just asking for trouble IMHO. Even more as both are of the same type. 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 0014505]: UseQt4 insists on linking with -lQtXml if QtSvg is requested
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14505 == Reported By:Orion Poplawski Assigned To: == Project:CMake Issue ID: 14505 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-10-22 15:18 EDT Last Modified: 2013-10-22 15:18 EDT == Summary:UseQt4 insists on linking with -lQtXml if QtSvg is requested Description: UseQt4 insists on linking with -lQtXml if QtSvg is requested. However, plplot's libplplotqtd.so uses QtSvg and does not need to link directly to QtXml. This seems to be the culprit: set(QT_QTSVG_MODULE_DEPENDS QTGUI QTXML QTCORE) == Issue History Date ModifiedUsername FieldChange == 2013-10-22 15:18 Orion PoplawskiNew 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] Perforce Patch for CTest
Oh, I see. Sure, I can see how that could become easily a hard to debug problem. On Tue, Oct 22, 2013 at 12:08 PM, Rolf Eike Beer e...@sf-mail.de wrote: Am Dienstag, 22. Oktober 2013, 11:51:52 schrieb Pedro Navarro: I would extend the regex in the DiffParser constructor to contain - at the end to make the propability that a filename with # in it would cause issues smaller. Also I find the usage of both Options and options in SetP4Options() an invitation for confusion (and possible errors). I'll change the regex. Although I verified it in debuggex to make sure we could correctly handle different combination of files with # and other characters in it, it makes sense to add the additional check. About the options, do you mean not using P4Options when doing an update if options for the update commands are given? I have to admit that I don't fully understand the difference between Update Options and VCS Specific options (I got that code from the GIT implementation) but Perforce has the notion of global and command specific flags. In this case, the global flags are the P4Options which are used to specify how do you connect to the server (host, port, username) and which client view to use, the other options are the flags you pass for the update command, which are completely different. I agree it can be confusing I meant that you have one variable called Options and one called options. This is just asking for trouble IMHO. Even more as both are of the same type. Eike -- 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] FindPkgConfig and CMAKE_PREFIX_PATH
On Tuesday 22 October 2013, Daniele E. Domenichelli wrote:
Hello all,
FindPkgConfig does not support the CMAKE_PREFIX_PATH variable.
This is because pkg-config uses the PKG_CONFIG_PATH and does not know
anything
about CMAKE_PREFIX_PATH.
As a consequence, pkg-config packages built and installed in a non standard
directory using ExternalProject, cannot be found, while cmake ones can
be easily
located setting the CMAKE_PREFIX_PATH variable.
Do you think it could make sense to add to FindPkgConfig something like
this?
set(_pkgconfig_path $ENV{PKG_CONFIG_PATH})
foreach(_dir ${CMAKE_PREFIX_PATH})
set(ENV{PKG_CONFIG_PATH} $ENV{PKG_CONFIG_PATH}:${_dir}/lib/pkgconfig)
endforeach()
[...] (search for package)
set(ENV{PKG_CONFIG_PATH} ${_pkgconfig_path})
good idea I think.
I guess it should also take lib64/ and the multiarch lib dirs into account.
You may have a look into GNUInstallDirs.cmake, there this is handled too.
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
[cmake-developers] Fwd: CMake System Prefix Path
Forwarding this for Ben. Would it be reasonable to have a way to not add the CMAKE_INSTALL_PREFIX to the CMAKE_SYSTEM_PREFIX_PATH? The install prefix is not cleared before the CI build on build.kde.org because the dependency graph is quite large (everything depends on Qt, most things depend on kdelibs, some things depend on kdepimlibs etc). Successful builds are uploaded to a master server and build nodes will re-download that if they have no version of the dependency. That re-download can be huge and take significant time, so it is avoided by also not clearing the install prefix on each of the build nodes. Is the only solution to this as Ben describes with passing NO_CMAKE_SYSTEM_PATH to CMake? Thanks, Steve. Original Message Subject:CMake System Prefix Path Date: Tue, 22 Oct 2013 17:03:26 +1300 From: Ben Cooksley bcooks...@kde.org To: Stephen Kelly steve...@gmail.com Hi Stephen, It has between pointed out to me on IRC that CMake automatically adds the install prefix path (CMAKE_INSTALL_PREFIX) to CMAKE_SYSTEM_PREFIX_PATH - which is included in the paths searched. This is rather unfortunate as it interferes in our CI system - we rely on CMake searching only normal system paths (like /usr) and the paths we specify (via CMAKE_PREFIX_PATH) in order to ensure our builds are clean. This means kdelibs[frameworks] builds have been succeeding when they should be failing. Is there any way around this issue other than ensuring /usr and /usr/local are included in CMAKE_PREFIX_PATH, and passing NO_CMAKE_SYSTEM_PATH to CMake? (As an aside, it seems that something in the stack Grantlee uses is definitely modifying CMAKE_SYSTEM_PREFIX_PATH as it contains /srv/jenkins/install/linux/x86_64/g++/common/shared - which is not the install prefix. Thanks, Ben -- 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] Open sourcing CMake Development
Hi! First, thanks to everyone on this list for the tremendous product that is CMake! I was curious if it would be possible to open source CMake's entire development by putting it on Github or a similar collaborative location. The CMake user base is so huge and diverse that doing this would surely gain contributors to improve CMake. Perhaps this has been discussed before and I didn't see it. Anyways, thanks for your consideration! Cheers, Jack -- 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] Fwd: CMake System Prefix Path
Alexander Neundorf wrote: Is the only solution to this as Ben describes with passing NO_CMAKE_SYSTEM_PATH to CMake? Is everything installed into its own separate directory, or everything into one common install directory ? Everything is installed to a separate directory, and each one is added to the relevant environment variables. So, build.kde.org *could* clear the install directory, but that would mean that if the build of kdelibs (for example) failed, the build of amarok (for example) on the same build node would first have to transfer the cached install tree from the master node. As that takes time, it is preferred to avoid that. Therefore the install tree is not cleared. 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] Fwd: CMake System Prefix Path
On Tuesday 22 October 2013, Alexander Neundorf wrote: On Tuesday 22 October 2013, Stephen Kelly wrote: Forwarding this for Ben. Would it be reasonable to have a way to not add the CMAKE_INSTALL_PREFIX to the CMAKE_SYSTEM_PREFIX_PATH? The install prefix is not cleared before the CI build on build.kde.org because the dependency graph is quite large (everything depends on Qt, most things depend on kdelibs, some things depend on kdepimlibs etc). Successful builds are uploaded to a master server and build nodes will re-download that if they have no version of the dependency. That re-download can be huge and take significant time, so it is avoided by also not clearing the install prefix on each of the build nodes. Is the only solution to this as Ben describes with passing NO_CMAKE_SYSTEM_PATH to CMake? Is everything installed into its own separate directory, or everything into one common install directory ? Is still cmake git next used for the builds ? It is only one line in UnixPaths.cmake, so a workaround for that special case could be to simply use a patched version of 2.8.12, which is the version required by kdelibs, and comment that one line out. 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] Perforce Patch for CTest
Attached is the new patch with Eike's recommendations.
Pedro
From d291fde15c8e94ec5c9b93f96714554acf706d02 Mon Sep 17 00:00:00 2001
From: Pedro Navarro pnava...@netflix.com
Date: Tue, 1 Oct 2013 18:49:47 -0700
Subject: [PATCH] Perforce support for CTest
---
Modules/CTest.cmake |5 +
Modules/DartConfiguration.tcl.in |7 +
Source/CMakeLists.txt |2 +
Source/CTest/cmCTestP4.cxx| 569 +
Source/CTest/cmCTestP4.h | 71
Source/CTest/cmCTestUpdateCommand.cxx |8 +
Source/CTest/cmCTestUpdateHandler.cxx | 26 +-
Source/CTest/cmCTestUpdateHandler.h |1 +
Tests/CMakeLists.txt | 23 ++
Tests/CTestUpdateCommon.cmake |2 +-
Tests/CTestUpdateP4.cmake.in | 263 +++
11 files changed, 975 insertions(+), 2 deletions(-)
create mode 100644 Source/CTest/cmCTestP4.cxx
create mode 100644 Source/CTest/cmCTestP4.h
create mode 100644 Tests/CTestUpdateP4.cmake.in
diff --git a/Modules/CTest.cmake b/Modules/CTest.cmake
index 643cd29..ada8655 100644
--- a/Modules/CTest.cmake
+++ b/Modules/CTest.cmake
@@ -149,6 +149,7 @@ if(BUILD_TESTING)
find_program(BZRCOMMAND bzr)
find_program(HGCOMMAND hg)
find_program(GITCOMMAND git)
+ find_program(P4COMMAND p4)
if(NOT UPDATE_TYPE)
if(EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/CVS)
@@ -180,6 +181,9 @@ if(BUILD_TESTING)
elseif(${_update_type} STREQUAL git)
set(UPDATE_COMMAND ${GITCOMMAND})
set(UPDATE_OPTIONS ${GIT_UPDATE_OPTIONS})
+ elseif(${_update_type} STREQUAL p4)
+set(UPDATE_COMMAND ${P4COMMAND})
+set(UPDATE_OPTIONS ${P4_UPDATE_OPTIONS})
endif()
set(DART_TESTING_TIMEOUT 1500 CACHE STRING
@@ -275,6 +279,7 @@ if(BUILD_TESTING)
CVS_UPDATE_OPTIONS
DART_TESTING_TIMEOUT
GITCOMMAND
+P4COMMAND
HGCOMMAND
MAKECOMMAND
MEMORYCHECK_COMMAND
diff --git a/Modules/DartConfiguration.tcl.in b/Modules/DartConfiguration.tcl.in
index 9e49ac7..68fadf6 100644
--- a/Modules/DartConfiguration.tcl.in
+++ b/Modules/DartConfiguration.tcl.in
@@ -52,6 +52,13 @@ GITCommand: @GITCOMMAND@
GITUpdateOptions: @GIT_UPDATE_OPTIONS@
GITUpdateCustom: @CTEST_GIT_UPDATE_CUSTOM@
+# Perforce options
+P4Command: @P4COMMAND@
+P4Client: @CTEST_P4_CLIENT@
+P4Options: @CTEST_P4_OPTIONS@
+P4UpdateOptions: @CTEST_P4_UPDATE_OPTIONS@
+P4UpdateCustom: @CTEST_P4_UPDATE_CUSTOM@
+
# Generic update command
UpdateCommand: @UPDATE_COMMAND@
UpdateOptions: @UPDATE_OPTIONS@
diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index 01e4f88..fd97a20 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -465,6 +465,8 @@ set(CTEST_SRCS cmCTest.cxx
CTest/cmCTestGIT.h
CTest/cmCTestHG.cxx
CTest/cmCTestHG.h
+ CTest/cmCTestP4.cxx
+ CTest/cmCTestP4.h
)
# Build CTestLib
diff --git a/Source/CTest/cmCTestP4.cxx b/Source/CTest/cmCTestP4.cxx
new file mode 100644
index 000..ac33997
--- /dev/null
+++ b/Source/CTest/cmCTestP4.cxx
@@ -0,0 +1,569 @@
+/*
+ CMake - Cross Platform Makefile Generator
+ Copyright 2000-2013 Kitware, Inc.
+
+ Distributed under the OSI-approved BSD License (the License);
+ see accompanying file Copyright.txt for details.
+
+ This software is distributed WITHOUT ANY WARRANTY; without even the
+ implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ See the License for more information.
+*/
+#include cmCTestP4.h
+
+#include cmCTest.h
+#include cmSystemTools.h
+#include cmXMLSafe.h
+
+#include cmsys/RegularExpression.hxx
+#include cmsys/ios/sstream
+#include cmsys/Process.h
+
+#include sys/types.h
+#include time.h
+#include ctype.h
+
+//
+cmCTestP4::cmCTestP4(cmCTest* ct, std::ostream log):
+ cmCTestGlobalVC(ct, log)
+{
+ this-PriorRev = this-Unknown;
+}
+
+//
+cmCTestP4::~cmCTestP4()
+{
+}
+
+//
+class cmCTestP4::IdentifyParser: public cmCTestVC::LineParser
+{
+public:
+ IdentifyParser(cmCTestP4* p4, const char* prefix,
+ std::string rev): Rev(rev)
+{
+this-SetLog(p4-Log, prefix);
+this-RegexIdentify.compile(^Change ([0-9]+) on);
+}
+private:
+ std::string Rev;
+ cmsys::RegularExpression RegexIdentify;
+
+ bool ProcessLine()
+{
+if(this-RegexIdentify.find(this-Line))
+ {
+ this-Rev = this-RegexIdentify.match(1);
+ return false;
+ }
+return true;
+}
+};
+
+//
+class cmCTestP4::ChangesParser: public cmCTestVC::LineParser
+{
+public:
+ ChangesParser(cmCTestP4* p4, const char* prefix) : P4(p4)
+{
+
Re: [cmake-developers] Perforce Patch for CTest
Good point :) Here's the new patch. GetWorkingRevision returns 0 instead
of empty now, eliminating the need to do the check in NoteOldRevision and
NoteNewRevision
Pedro
On Tue, Oct 22, 2013 at 2:49 PM, Rolf Eike Beer e...@sf-mail.de wrote:
Am Dienstag, 22. Oktober 2013, 14:36:36 schrieb Pedro Navarro:
Attached is the new patch with Eike's recommendations.
One more nitpick ;)
+ this-OldRevision = this-GetWorkingRevision();
+ if(this-OldRevision.empty())
+{
+this-OldRevision = 0;
+}
That code comes twice, for the only 2 callers of GetWorkingRevision(). I
would
say just modify that method to return 0 in that case.
Eike
From d2cb109754699cbc82ba4334f448f41028642adc Mon Sep 17 00:00:00 2001
From: Pedro Navarro pnava...@netflix.com
Date: Tue, 1 Oct 2013 18:49:47 -0700
Subject: [PATCH] Perforce support for CTest
---
Modules/CTest.cmake |5 +
Modules/DartConfiguration.tcl.in |7 +
Source/CMakeLists.txt |2 +
Source/CTest/cmCTestP4.cxx| 569 +
Source/CTest/cmCTestP4.h | 71
Source/CTest/cmCTestUpdateCommand.cxx |8 +
Source/CTest/cmCTestUpdateHandler.cxx | 26 +-
Source/CTest/cmCTestUpdateHandler.h |1 +
Tests/CMakeLists.txt | 23 ++
Tests/CTestUpdateCommon.cmake |2 +-
Tests/CTestUpdateP4.cmake.in | 263 +++
11 files changed, 975 insertions(+), 2 deletions(-)
create mode 100644 Source/CTest/cmCTestP4.cxx
create mode 100644 Source/CTest/cmCTestP4.h
create mode 100644 Tests/CTestUpdateP4.cmake.in
diff --git a/Modules/CTest.cmake b/Modules/CTest.cmake
index 643cd29..ada8655 100644
--- a/Modules/CTest.cmake
+++ b/Modules/CTest.cmake
@@ -149,6 +149,7 @@ if(BUILD_TESTING)
find_program(BZRCOMMAND bzr)
find_program(HGCOMMAND hg)
find_program(GITCOMMAND git)
+ find_program(P4COMMAND p4)
if(NOT UPDATE_TYPE)
if(EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/CVS)
@@ -180,6 +181,9 @@ if(BUILD_TESTING)
elseif(${_update_type} STREQUAL git)
set(UPDATE_COMMAND ${GITCOMMAND})
set(UPDATE_OPTIONS ${GIT_UPDATE_OPTIONS})
+ elseif(${_update_type} STREQUAL p4)
+set(UPDATE_COMMAND ${P4COMMAND})
+set(UPDATE_OPTIONS ${P4_UPDATE_OPTIONS})
endif()
set(DART_TESTING_TIMEOUT 1500 CACHE STRING
@@ -275,6 +279,7 @@ if(BUILD_TESTING)
CVS_UPDATE_OPTIONS
DART_TESTING_TIMEOUT
GITCOMMAND
+P4COMMAND
HGCOMMAND
MAKECOMMAND
MEMORYCHECK_COMMAND
diff --git a/Modules/DartConfiguration.tcl.in b/Modules/DartConfiguration.tcl.in
index 9e49ac7..68fadf6 100644
--- a/Modules/DartConfiguration.tcl.in
+++ b/Modules/DartConfiguration.tcl.in
@@ -52,6 +52,13 @@ GITCommand: @GITCOMMAND@
GITUpdateOptions: @GIT_UPDATE_OPTIONS@
GITUpdateCustom: @CTEST_GIT_UPDATE_CUSTOM@
+# Perforce options
+P4Command: @P4COMMAND@
+P4Client: @CTEST_P4_CLIENT@
+P4Options: @CTEST_P4_OPTIONS@
+P4UpdateOptions: @CTEST_P4_UPDATE_OPTIONS@
+P4UpdateCustom: @CTEST_P4_UPDATE_CUSTOM@
+
# Generic update command
UpdateCommand: @UPDATE_COMMAND@
UpdateOptions: @UPDATE_OPTIONS@
diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index 01e4f88..fd97a20 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -465,6 +465,8 @@ set(CTEST_SRCS cmCTest.cxx
CTest/cmCTestGIT.h
CTest/cmCTestHG.cxx
CTest/cmCTestHG.h
+ CTest/cmCTestP4.cxx
+ CTest/cmCTestP4.h
)
# Build CTestLib
diff --git a/Source/CTest/cmCTestP4.cxx b/Source/CTest/cmCTestP4.cxx
new file mode 100644
index 000..32e8486
--- /dev/null
+++ b/Source/CTest/cmCTestP4.cxx
@@ -0,0 +1,569 @@
+/*
+ CMake - Cross Platform Makefile Generator
+ Copyright 2000-2013 Kitware, Inc.
+
+ Distributed under the OSI-approved BSD License (the License);
+ see accompanying file Copyright.txt for details.
+
+ This software is distributed WITHOUT ANY WARRANTY; without even the
+ implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ See the License for more information.
+*/
+#include cmCTestP4.h
+
+#include cmCTest.h
+#include cmSystemTools.h
+#include cmXMLSafe.h
+
+#include cmsys/RegularExpression.hxx
+#include cmsys/ios/sstream
+#include cmsys/Process.h
+
+#include sys/types.h
+#include time.h
+#include ctype.h
+
+//
+cmCTestP4::cmCTestP4(cmCTest* ct, std::ostream log):
+ cmCTestGlobalVC(ct, log)
+{
+ this-PriorRev = this-Unknown;
+}
+
+//
+cmCTestP4::~cmCTestP4()
+{
+}
+
+//
+class cmCTestP4::IdentifyParser: public cmCTestVC::LineParser
+{
+public:
+ IdentifyParser(cmCTestP4* p4, const char* prefix,
+ std::string rev):
Re: [cmake-developers] Open sourcing CMake Development
Oh wow! Duh. My apologies. I'll check those out. Maybe then my suggestion should change to putting a link to those pages in an obvious place on cmake.org, for instance on the Get Involved page. Thanks again. Cheers, Jack On Tue, Oct 22, 2013 at 8:38 PM, David Cole dlrd...@aol.com wrote: I was curious if it would be possible to open source CMake's entire development by putting it on Github or a similar collaborative location. The CMake user base is so huge and diverse that doing this would surely gain contributors to improve CMake. U. Like this? https://github.com/Kitware/**CMake https://github.com/Kitware/CMake Perhaps this has been discussed before and I didn't see it. Anyways, thanks for your consideration! The main official repo is at cmake.org, but there is a mirror pushed to GitHub automatically... You can help contribute to CMake using git if you like. Start here: http://www.cmake.org/Wiki/**CMake/Git/Develophttp://www.cmake.org/Wiki/CMake/Git/Develop (easily found simply by googling for cmake git) HTH, David -- 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
