Hi,
Attached is a patch to add Perforce support to CTest. I searched for
instances of GIT in the CTest code and added the equivalent P4
functionality. Hopefully I didn't miss anything!
The source code is very inspired on the GIT implementation and it's fully
featured:
- Commiters are resolved
Hi guys, just checking: am I expected to do anything else with the P4 patch
or is it now in your hands and will eventually be integrated?
Thanks!
Pedro
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messag
Hi all,
I've written a patch to add Perforce support for CTest 2.8. Although it
still needs a little bit more work (I need to look into what I'm supposed
to do with Nightly builds ) it properly notifies CTest of all details about
check ins, revision numbers, authors and their E-Mail address (by ma
Am Mittwoch, 2. Oktober 2013, 12:00:18 schrieb Pedro Navarro:
> Hi,
>
> Attached is a patch to add Perforce support to CTest. I searched for
> instances of GIT in the CTest code and added the equivalent P4
> functionality. Hopefully I didn't miss anything!
>
> The source code is very inspired on
>
>
> >- It requires an English version of Perforce (use the P4_OPTIONS
> >variable, documented below to pass the -L switch to change the message
> >language if you installation has a different one). It shouldn't be too
> > hard to change the regular expressions used for parsing to not
Am Mittwoch, 2. Oktober 2013, 13:10:20 schrieb Pedro Navarro:
> > >- It requires an English version of Perforce (use the P4_OPTIONS
> > >variable, documented below to pass the -L switch to change the
> > >message
> > >language if you installation has a different one). It shouldn't b
The issue with the P4LANGUAGE environment variable, as well as the -L
switch is that I don't know the language string I need to set it to.
Another thing is that Perforce says that it will change the text of the
error messages, so it's not clear if the ouput I'm parsing will be affected
or not. I gu
Attached is a new patch with Rolf's suggestions (improved regex and usage
of size_type to go through the Options vector). I just amended my commit
and created a new patch file, instead of doing two smaller ones.
Pedro
On Wed, Oct 2, 2013 at 2:28 PM, Pedro Navarro wrote:
> The issue with the P4
On 10/02/2013 06:00 PM, Pedro Navarro wrote:
> Attached is a new patch with Rolf's suggestions (improved regex and
> usage of size_type to go through the Options vector).
Thanks. (BTW, he goes by Eike.)
> I just amended my commit and created a new patch file,
> instead of doing two smaller ones.
We deployed CTest today on our production machine and found an off by one
error when describing changelists. I've updated the patch and attached it
to this mail. Other than that, we have ctest running here with no problems!
Pedro
On Thu, Oct 3, 2013 at 10:19 AM, Brad King wrote:
> On 10/02/201
On 10/10/2013 04:01 PM, Pedro Navarro wrote:
> Hi guys, just checking: am I expected to do anything else with
> the P4 patch or is it now in your hands and will eventually be integrated?
As requested here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8085/focus=8098
the pat
I saw that and I thought that was meant for Eike. Ok I'll work on the test
cases and I'll see what I can do about the nightly dashboard submissions.
Pedro
On Thu, Oct 10, 2013 at 1:14 PM, Brad King wrote:
> On 10/10/2013 04:01 PM, Pedro Navarro wrote:
> > Hi guys, just checking: am I expected
I'm developing the test, working against Perforce's free 20 user server.
What's the procedure build and run the test from a CMake source build?
Thanks!
PEdro
On Thu, Oct 10, 2013 at 1:40 PM, Pedro Navarro wrote:
> I saw that and I thought that was meant for Eike. Ok I'll work on the test
> cas
On 10/14/2013 2:41 PM, Pedro Navarro wrote:
> I'm developing the test, working against Perforce's free 20 user server.
> What's the procedure build and run the test from a CMake source build?
In the build tree run
bin/ctest -R CTest.UpdateP4
assuming you've modified Tests/CMakeLists.txt appropr
Hi!
I have the test succesfully running using the provided framework for
CTestUpdate, so I have a new CTest.UpdateP4 test. Right now it runs against
a local p4d server instance that you can download for free from Perforce.
I'm imagining that, depending on the testing machine, we might need to be
On 2013-10-15 18:44, Pedro Navarro wrote:
I'm imagining that, depending on the testing machine, we might need to be
able to specify where the perforce server is located, if it's not the local
machine (using either a command line switch or an environment variable). Is
there any infrastructure for
That's exactly my point. Is it ok to rely on environment variables (P4PORT,
P4HOST), ie, expect the build machine to be set up in a way before running
the tests or are those values passed in some kind of configuration file,
added to the CMake Cache or passed as -D?
Pedro
On Tue, Oct 15, 2013 at
On 10/15/2013 07:39 PM, Pedro Navarro wrote:
> That's exactly my point. Is it ok to rely on environment variables (P4PORT,
> P4HOST), ie, expect the build machine to be set up in a way before running
> the tests or are those values passed in some kind of configuration file,
> added to the CMake
Sounds good. Those environment variables are read automatically by
Perforce's command line tools, so there's nothing to do on the test's end
then.
Pedro
On Wed, Oct 16, 2013 at 5:23 AM, Brad King wrote:
> On 10/15/2013 07:39 PM, Pedro Navarro wrote:
> > That's exactly my point. Is it ok to rel
I was thinking that as the test requires the p4 tool to be installed, we
might as well require also p4d (the server, which is now free for up to 20
users). In that case the test can bring up a local server and work against
it which, in the end, will create less issues as the p4 database will be
del
On 10/16/2013 03:11 PM, Pedro Navarro wrote:
> I was thinking that as the test requires the p4 tool to be installed,
> we might as well require also p4d (the server, which is now free for
> up to 20 users). In that case the test can bring up a local server
> and work against it which, in the end, w
Ok, I have the patch working and I'm going to send it soon. One question,
is it possible to launch a detached process from within CMake? If I use
EXECUTE_PROCESS to start p4d, CMake waits for it to finish so -for now- I'm
launching the Perforce daemon outside CMake.
Pedro
On Wed, Oct 16, 2013 at
On 10/17/2013 1:52 PM, Pedro Navarro wrote:
Ok, I have the patch working and I'm going to send it soon. One
question, is it possible to launch a detached process from within CMake?
If I use EXECUTE_PROCESS to start p4d, CMake waits for it to finish so
-for now- I'm launching the Perforce daemon o
On 10/17/2013 02:18 PM, Bill Hoffman wrote:
> On 10/17/2013 1:52 PM, Pedro Navarro wrote:
>> Ok, I have the patch working and I'm going to send it soon. One
>> question, is it possible to launch a detached process from within CMake?
>> If I use EXECUTE_PROCESS to start p4d, CMake waits for it to fi
I experimented with nohup but from inside a shell script that was being
executed from execute_process, but that didn't work. I'll give that a try,
thanks!
There happens to be a way to cleanly shutdown perforce, executing "p4 admin
stop", so this could mean that we can start p4d if it's present and
On 10/17/2013 03:23 PM, Pedro Navarro wrote:
> I experimented with nohup but from inside a shell script
> that was being executed from execute_process, but that didn't work.
You also need to disconnect the stdout/stderr pipes by redirecting
them to /dev/null. Then execute_process can fully let go
Am Donnerstag, 17. Oktober 2013, 14:18:34 schrieb Bill Hoffman:
> On 10/17/2013 1:52 PM, Pedro Navarro wrote:
> > Ok, I have the patch working and I'm going to send it soon. One
> > question, is it possible to launch a detached process from within CMake?
> > If I use EXECUTE_PROCESS to start p4d, C
On 10/17/2013 04:56 PM, Rolf Eike Beer wrote:
> We should think if this should be something that is needed. Running some sort
> of background process is a common pattern for all sorts of tests. Often
> really
> detaching is not needed, It is usually sufficient to have one process running
> in
On 10/17/2013 4:59 PM, Brad King wrote:
As I explained in a sibling response the KWSys Process library
has support for creating detached processes. It should only be
a matter of exposing that through execute_process command options.
+1, this does come up a lot. It would be good to have this ex
On 2013-10-17 16:59, Brad King wrote:
On 10/17/2013 04:56 PM, Rolf Eike Beer wrote:
We should think if this should be something that is needed. Running some sort
of background process is a common pattern for all sorts of tests. Often really
detaching is not needed, It is usually sufficient to ha
Attached is the latest version of the Perforce support patch for CTest.
I've added a test (CTest.UpdateP4) that launches a Perforce server
listening on a custom port and performs the same operations as other VCS
tools. Some release notes:
- Unix is expected. Windows could work (it's a matter of
Am Montag, 21. Oktober 2013, 17:56:36 schrieb Pedro Navarro:
> Attached is the latest version of the Perforce support patch for CTest.
> I've added a test (CTest.UpdateP4) that launches a Perforce server
> listening on a custom port and performs the same operations as other VCS
> tools. Some releas
>
>
>
> 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)
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
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
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 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
Attached is the new patch with Eike's recommendations.
Pedro
From d291fde15c8e94ec5c9b93f96714554acf706d02 Mon Sep 17 00:00:00 2001
From: Pedro Navarro
Date: Tue, 1 Oct 2013 18:49:47 -0700
Subject: [PATCH] Perforce support for CTest
---
Modules/CTest.cmake |5 +
Modules/Da
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 t
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 wrote:
> Am Dienstag, 22. Oktober 2013, 14:36:36 schrieb Pedro Navarro:
> >
On 10/22/2013 06:11 PM, Pedro Navarro wrote:
> Good point :) Here's the new patch.
Great, thanks! I've applied it:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c63ecee3
with minor tweaks:
* Updated commit author date to when you sent the email
* Wrote more extensive commit message
* Mar
Thanks a lot! Glad we could contribute.
What's the process for changes? :) Adding support for P4Web in CDash made
me realize that maybe we need to change how revisions are reported in
Update.xml (file revisions instead of changelists), I'm looking into that
right now.
Pedro
On Wed, Oct 23, 2013
Am 23.10.2013 22:49, schrieb Brad King:
On 10/22/2013 06:11 PM, Pedro Navarro wrote:
Good point :) Here's the new patch.
Great, thanks! I've applied it:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c63ecee3
CMake/Source/CTest/cmCTestP4.cxx: In member function ‘virtual void
cmCTestP
On 10/24/2013 03:11 AM, Rolf Eike Beer wrote:
> CMake/Source/CTest/cmCTestP4.cxx: In member function ‘virtual void
> cmCTestP4::LoadRevisions()’:
> CMake/Source/CTest/cmCTestP4.cxx:469:32: warning: conversion to ‘int’
> from ‘std::vector >::size_type {aka long
> unsigned int}’ may alter its valu
On 10/24/2013 08:17 AM, Brad King wrote:
> Also std::size_t does not work on VS 6. Both fixed:
Also a couple fixes to the test:
CTest.UpdateP4: Fix test when p4 client is not in PATH
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ee51ec64eb
CTest.UpdateP4: Run test in directory with space i
On 10/23/2013 08:43 PM, Pedro Navarro wrote:
> Thanks a lot! Glad we could contribute.
>
> What's the process for changes? :) Adding support for P4Web
> in CDash made me realize that maybe we need to change how
> revisions are reported in Update.xml (file revisions instead
> of changelists), I'm l
That's right, p4 usually doesn't create a .p4 file so there's no way to
tell by looking at the file system if a directory is under p4 control or
not. Some people set a P4CONFIG variable that points to a .p4 or .p4config
file and that's what DetectVCS looks for to identify the VCS as perforce.
The o
On 10/24/2013 03:57 PM, Pedro Navarro wrote:
> That's right, p4 usually doesn't create a .p4 file
I think it is fine for the test to not place .p4 files
since that is representative of real use cases.
> Ideally each VCS implementation could have a way to tell
> CTest if a directory it's under tha
Turns out that I could find a way to have P4Web do diffs based on
changelists, so no changes to CTest where needed. I have P4Web now working
on CDash. What's the process to submit CDash patches? I just signed up for
its mailing list.
About the DetectVCS refactor, I'll take a stab at it!
Pedro
O
CDash now supports P4Web for viewing files and diffs and the daily changes
are read from a Perforce repository! I'll see what happens tonight, when
the nightly builds are run and will create a thread with the patches in the
CDash mailing list if succesful.
Pedro
On Thu, Oct 24, 2013 at 2:03 PM,
On 10/24/2013 05:03 PM, Pedro Navarro wrote:
> Turns out that I could find a way to have P4Web do diffs based
> on changelists, so no changes to CTest where needed. I have
> P4Web now working on CDash. What's the process to submit CDash
> patches? I just signed up for its mailing list.
Great, than
>
>
>
> BTW, the UpdateP4 test failed on our nightly build again because
> of timing issues with the busy system trying to start p4d. I
> changed the way we wait for the server to start:
>
> CTest.UpdateP4: Wait for p4d to start more robustly
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=
On 09/30/2013 08:36 PM, Pedro Navarro wrote:
> I've written a patch to add Perforce support for CTest 2.8. Although it still
> needs a little bit more work (I need to look into what I'm supposed to do
> with Nightly builds ) it properly notifies CTest of all details about check
> ins, revision n
52 matches
Mail list logo
