hi all :)
there's a feature split I'm itching for in Test::Builder, etc - the
ability to call is() and have it emit TAP free from the confines of
plan(). not that I don't want to call plan() (or no_plan) but I want to
do that in a completely separate perl interpreter. for example, I want
to do s
>> so, thoughts or ideas? am I making any sense?
>
>
> Yes, you are.
*whew*
:)
> I think that the subprocess can load Test::More and
> friends like this:
>
> use Test::More no_plan => 1;
> Test::More->builder->no_header(1);
cool, thanks.
>
> That will set No_Plan, Have_Plan, and No_Hea
>> One of the problems is going to be numbering, surely?
but it shouldn't need to be, right? I mean, TAP is merely a protocol and
there shouldn't be a requirement that the bookkeeping happen in the same
process as the TAP emitting process I wouldn't think. in fact, if someone
were implementing
chromatic wrote:
> On Wednesday 15 March 2006 12:25, Jeffrey Thalhammer wrote:
>
>
>>I'm sure I could clean this up by opening a pipe
>>instead of using backticks and output redirection.
>>But even that doesn't smell very good. I've looked
>>around on CPAN, but I have not yet found a Test::
>>
>>> I've long intended to take t/test.pl from the Perl core distribution
>>> and wrap
>>> up at least its runperl() in a Test:: module. Perhaps that would
>>> work for
>>> you?
>>
>>
>> compile_ok() ?
>>
>> --Geoff
>>
>
> It is unclear from Geoff's message above whether he is asserting that
>
hi all :)
for those interested in both php and perl, it seems that php's native .phpt
testing feature will soon produce TAP compliant output - see greg beaver's
comments here
http://shiflett.org/archive/218#comments
so, TAP is slowly dominating the world... but we all knew that already :)
wha
David Cantrell wrote:
> Geoffrey Young wrote:
>
>>> "Only the simplest of designs benefits from pre-coded tests, unless
>>> you have
>>> unlimited developer time."
>>
>> needless to say I just don't believe this.
>
>
>
> Apache::Test looks like it might be the way to go. But it doesn't seem
> to play very nicely with Test::More,
that's not really true. yes, Apache-Test was based on Test.pm (for various
reasons I won't get into here) but I added Test::More support and use it all
the time. grep for stuff lik
Adam Kennedy wrote:
> I'd also add a small warning in that Apache::Test does seem to want to
> dominate the entire test suite (run everything from TEST) and so may not
> be as suitable in cases where you have 50-500 test scripts already, and
> you just want a few to work with Apache::Test and a n
we should keep this on list :)
Adam Kennedy wrote:
>
>
> Geoffrey Young wrote:
>
>>
>> Adam Kennedy wrote:
>>
>>> I'd also add a small warning in that Apache::Test does seem to want to
>>> dominate the entire test suite (run everything
>
> A-T requires me to do things differently, and it's that difference that
> introduces the lack of flexibility.
I had a bunch of foo written that I removed, mainly because this is the real
issue, for you I guess - the idea that different is somehow bad or
inflexible, that anyone who creates so
Andy Lester wrote:
>
> I'm adding a section to Test::Harness::TAP on non-Perl TAP.
>
> http://svn.perl.org/modules/Test-Harness/trunk/lib/Test/Harness/TAP.pod
>
> If you know of one, please send me some text to add.
all the big PHP players now produce TAP
o phpt (outputs TAP by default as
chromatic wrote:
> On Monday 17 April 2006 18:50, Ovid wrote:
>
>
>>The only problem I see with that is the occasional buffering errors I
>>see on my Mac where the STDERR and STDOUT don't line up.
>
>
> Agreed. Is it too late to send everything to STDOUT where it belongs?
just for everyone'
Adam Kennedy wrote:
>
>>> Schwern made one small change in the STDERR format, and the recursive
>>> cascade of failing test-testing modules hit something like 3000 CPAN
>>> distributions.
>>
>>
>> While I agree that this caused problems, those modules were relying on a
>> format that was not spe
Pete Krawczyk wrote:
> Subject: skip_all with Test::More?
> From: Tels <[EMAIL PROTECTED]>
> Date: Wed, 31 May 2006 17:53:46 +0200
>
> }
> }use Test::More;
> }
> }plan tests => 123;
> }
> }skip_all( 'reason' ) if ...;
> }
> }# tes
> Since you're using C++, you can probably use libtap
> (http://www.onlamp.com/pub/a/onlamp/2006/01/19/libtap.html and
> http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/LibTap) for writing the tests and
> then you could use a Perl harnes to collect those results.
just out of curiosity, has anyone got
Nik Clayton wrote:
> Geoffrey Young wrote:
>
>>> Since you're using C++, you can probably use libtap
>>> (http://www.onlamp.com/pub/a/onlamp/2006/01/19/libtap.html and
>>> http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/LibTap) for writing the
>>> te
hi all :)
so, as a standard practice, I start with
use_ok($class);
as the first test in each file, the idea being that if the class doesn't
compile I shouldn't care about the results of the rest of the test - I
know immediately that subsequent failures are because I introduced a
typo or someth
sorry for dropping in on this late, but it was a holiday weekend :)
> * How can I help?
>
> Provide use cases, what would you want to do with Test::Harness if you
> could? What are you doing with Straps? What features do other
> testing systems (JUnit, for example) have that you'd like to see i
Geoffrey Young wrote:
> I've mentioned the idea of making it simple to use
> plan() and Test::More functions before
blarg... insert "separately" ^ here. all the rest is pretty simple
already :)
--Geoff
Michael G Schwern wrote:
> On 2/9/06, Geoffrey Young <[EMAIL PROTECTED]> wrote:
>
>> > This works:
>>
>> yes, excellent randy. thanks for that. it still seems a little
>> hackish but
>> that's ok - hackish works for me if it means I can do w
Ovid wrote:
> - Original Message From: Jonathan Rockway <[EMAIL PROTECTED]>
>
>> What else is TAP targeted to? C / C++ / Java?
>
>
> PHP tests often use TAP (don't know the name)
almost all of the php test frameworks now offer TAP support - see
http://search.cpan.org/dist/Test-Harn
> However, most perl tests don't care about TAP, they use Test::More and
> Test::Harness and happen to exchange data via TAP. If Test::More and
> Test::Harness decied to use "YAP" (YAML Anything Protocol? :), then most
> applications would probably never notice.
most _perl_ applications would ne
Jonathan Rockway wrote:
> While I agree with David, this argument is almost completely pointless.
> Nobody reads the raw TAP output!
are you serious? listen to what they people here are saying - we _all_
read the raw TAP output, all the time, and not because we're TAP
developers interested in th
Vsevolod (Simon) Ilyushchenko wrote:
> Hi,
>
> I'd like to suggest a module that I came up with to test CGI file
> uploading logic. I have not found anything else like it.
have you seen Apache-Test yet?
http://search.cpan.org/dist/Apache-Test/
I find it hard to understand modules like this a
Ricardo SIGNES wrote:
> Yesterday, hide gave me some sweet example code to use
> HTTP::Server::Simple and Test::WWW::Mechanize to test Rubric's CGI bits.
> I've started working with them, and they make me happy.
>
> I've realized that the server, which is forked from the test script,
> doesn't h
>>> This seems unfortunate for at least two reasons:
>>> 1) it ends up taking a really long time to run the tests. At some
>>> point, maybe long enough that nightly tests become prohibitive (even
>>> more so for continuous integration).
> We have a substantial Perl code base (as I've said sever
> http://www.justatheory.com/code/Test.Simple-0.10/tests/index.html?
> verbose=1
that's just awesome :)
nice work.
--Geoff
> (I deliberately
> did *not* list IO::Capture as a prerequisite in Makefile.PL because I
> didn't want to force users to install that module. I simply wanted them
> to use it during testing and then throw it away.
this is the start of the right attitude I think - when your testing
environment r
Michael G Schwern wrote:
> What I'm looking for is ideas about more things it could do that would
> be useful for most testing libraries. What scaffolding do module authors
> find themselves implementing?
if there were a better way to do this:
push @ISA, qw(Test::Harness::Straps);
$Test:
They add some value to me (show that at least something works).
>>>
>>>Either they're valuable enough that you install their prerequisites or
>>>they're not.
>
>
> But how am I supposed to find this out? I dont even know whether the
> required modules are used for the tests only, without di
Andy Lester wrote:
>> Usually, Test::* modules are only used for the test phase.
>
>
> I really don't understand the idea of "only used for the test phase",
there is clearly a distinction between the code required for a given module
to compile and run in a production environment and the code r
Andy Lester wrote:
>> yeah, well, you could say that. last time I installed my washer I said
>> "looks pretty level to me, but I know where my level is if it makes a
>> racket"
>
>
> That's fine, but I'm still not shipping my washing machines without
> explicit instructions to level the dam
> I'd really love to use Devel::Cover - I love the effect mastering the
> request/response Apache::Test framework has had on my code, and I really
> want to start using code coverage as part of my toolkit.
yah, this is a bit more complex than it probably ought to be, but I guess
that's by design.
> [snip - ah, helpful, now I understand how to use the testcover target]
:)
> Devel::Cover is reporting
> 100% statement coverage for a number of modules for which there are no tests
> as of yet (legacy modules I have yet to revisit)
I don't think that's unusual - D::C will aggregate all the r
Hilary Holz wrote:
Okay - here's what I've figured out - D::C is not recording any coverage
info when I run a test in t/apache. D::C is recording coverage for all the
tests that are in the t/ directory - and the reports are in the realm of the
reasonable.
Have you had D::C collect coverage sta
> No, not when I run the example out of the box - I had to move the
> PerlPassEnv directives to extra.conf.in and rebuild (this makes sense,
> though, as extra.conf is processed before modperl_extra.pl, while
> extra.last.conf is processed after - perhaps you fixed your local copy and
> haven't up
hi all :)
I just commited a patch to Apache-Test in svn that removes all the
additional work involved with getting Devel::Cover to work for server side
tests. now a simple 'make testcover' should be all you need to do to get
coverage results from code within handler() subroutines - no more adding
> Nice work, Geoff
:)
>
> A few issues:
>
> 1)
>
> % make testcover
> Cannot run testcover action unless Devel::Cover is installed
>
> and after installing Devel::Cover it still gives the same error, since
> it's hardcoded in Makefile.PL. May be adding a check and suggesting to
> rebuild Mak
[Torsten Fortsch ]
added Apache::TestRunPHP and Apache::TestConfigPHP classes,
which provide a framework for server-side testing via PHP scripts
[Geoffrey Young]
fix problem with multiple all.t files where only the final
file was being run through the test harness. [Geoffrey Young]
Documented
> Changing the subject slightly, is there any guidance on what people
> should write in the name/comment/label?
>
> I ask because several times I've been puzzled by a test failure
> where the message printed is ambiguous. Compare these two:
>
> not ok 42 - is red
>
> not ok 42 - sho
Michael G Schwern wrote:
> On Tue, Dec 21, 2004 at 04:53:18PM +0100, Tels wrote:
>
>>On Tuesday 21 December 2004 08:53, Michael G Schwern wrote:
>>
>>>I've gotten absolutely no response about Test::Legacy. Is anybody
>>>using it? Anybody tried migrating old Test.pm based tests with it?
>>
>>I
> But for all Test::Builder based modules you can get the same intent with
> Test::Builder->reset.
yup, I used that for the port away from Test.pm - works like a charm :)
--Geoff
Ovid wrote:
> Is anyone even using THS?
/me raises his hand
> If anything, I
> suspect there are a tiny handful of people who have played with it, but
> haven't really used it since it's not as useful as it could be.
I got Apache-Test to run .php scripts in under 10 lines by subclassing
strap
> This is helpful for processing bug reports, so I don't have to make
> second trip back to the user to ask: "What version of CGI.pm where you
> using?".
yeah, I'll second this, at least so far as adding a version component to
Test::More goes (which is different than adding a TAP version, which
> Hm, that does seem valuable. Should all test modules report their
> versions by default, though?
well, my thought was that it was more important to list the source of the
comparison operators the user uses (like is() or eq_array()) than it was the
internal stuff that, say, interfaces with Test
Joe Schaefer wrote:
> we should be able to communicate TAP via HTTP, SMTP, etc.).
TAP::Lite anyone?
/me ducks
;)
--Geoff
Ian Langworth wrote:
> On 30.Nov.2004 09:57AM -0600, Andy Lester wrote:
>
>
>> plan tests => 14, have( "Foo::Wango" ), moon_phase eq "waning", etc;
>
>
> Where does the reason fit into this syntax?
well, this syntax doesn't exist in Test::More at the moment (though I
probably should get ar
Ian Langworth wrote:
> On 12.Mar.2005 11:41PM -0500, Geoffrey Young wrote:
>
>
>>nevertheless, what you are replying to was just a discussion
>>about a feature that doesn't exist in the standard Test::More
>>toolkit but was brought up because Apache-Test's
Mark Stosberg wrote:
> On 2005-03-13, Geoffrey Young <[EMAIL PROTECTED]> wrote:
>
>>nevertheless, what you are replying to was just a discussion about a feature
>>that doesn't exist in the standard Test::More toolkit but was brought up
>>because Apache-Test&#
Michael G Schwern wrote:
> On Sat, Mar 12, 2005 at 11:41:08PM -0500, Geoffrey Young wrote:
>
>>well, this syntax doesn't exist in Test::More at the moment (though I
>>probably should get around to a patch like I promised) - it's only in
>>Apache-Test.
>
&
hi all :)
following up on the discussion from a few months ago but renewed over the
weekend, here is Test::Plan. basically all it does is carry over the exact
syntax and helper functions we are already using in Apache-Test land to the
greater community.
I'm still working up additional tests, but
> test => { TESTS => join ' ', map { glob } qw( t/*/*.t t/*/*/*.t ) },
but slashes aren't portable, right? I don't think you can get rid of
File::Spec.
> Also, I agree that the use-Test-Plan-after-Test-More caveat is icky.
well, it's a caveat, not a requirement :)
the way it works now is t
David Wheeler wrote:
> On Apr 7, 2005, at 5:55 PM, Michael G Schwern wrote:
>
>> If you have isDeeply() there's little point to the eq* salad.
>
>
> Hrm, fair enough. I'll comment them out, then...
well, a few thoughts here...
as someone familiar with T::M and not javascript, were I to try t
David Wheeler wrote:
> On May 5, 2005, at 04:26 , Adrian Howard wrote:
>
Here's a weird idea: how about the option of AJAXing the test
harness results back to a receiving server somewhere that
understands TAP? Bingo: TAP testing of JS embedded in web pages in
its native ha
hi paul.
I've found that in a statement like
$x{foo} ||= 1;
I can't ever satisfy the first condition in the "condition coverage" matrix
(0,0) since 1 is always true. is it desirable to remove fixed truth values
like this from the truth table?
I tried taking a look at adding the condition t
> This is unlikely to be the only case in which I have not fully
> understood the subtleties of the op tree, and so I am grateful for
> reports such as this.
I'll keep them coming, then :)
>
> The following patch should fix it, and will be in the next release,
> hopefully coming next week:
exce
> Full coverage isn't always possible, and the lack of it isn't
> necessarily a problem.
I fully agree. however, once you start using a tool like this, management
will inevitably ask "what's that 93% about?" and the answer is sometimes
complex and subject to judgement: "well, Devel::Cover is j
>> I might like to signal Devel::Cover that func() has a constant return (or
>> lack thereof).
>
>
> I don't know if I would like this feature. To me it would allow you to
> falsely skew the results of the Devel::Cover output. I look at
> Devel::Cover as a harshly objective analysis of my test-c
chromatic wrote:
> On Fri, 2004-05-21 at 09:02, Geoffrey Young wrote:
>
>
>>another thing that is keeping me from 100% right now is the
>>classic
>>
>> my $class = ref $self || $self;
>>
>>where the only way to satisfy the conditional is to
> Before I get too deep into an implementation, I'd like to poll the group about
> how you would use this feature and like it to behave. My thoughts and plans follow.
>
> For the coverage summary, the numbers represent actual coverage, but the colors
> are based upon actual coverage + analysis. S
Tony Bowden wrote:
> Is there any simple way to remove the test files themselves from the
> Devel::Cover results? i.e. just see the coverage analysis of the files
> being tested rather than all the t/* files as well?
>
> We want to monitor the total coverage over time on a project, and it
> woul
> The other concern I've had with our style of xUnit testing is that we're testing
> behavior, but not
> the actual data. With Test::More, we tested against a copy of the live database
> (when possible --
> but this definitely caused some issues) and we sometimes caught data problems that
> xU
hi paul :)
I recently discovered an issue with nested subroutines while using
Devel::Cover with Parse::Yapp. the basic issue is that some subroutines are
not discovered by Devel::Cover and thus no metrics are generated.
there are two files in the tarball. Foo.pm is a minimal test case showing
t
> Thanks a lot for the test cases. I think there are two separate bugs
> here, but I'm only going to take responsibility for one ;-)
:)
>
> First, mine. The problem with Foo.pm (the minimal test case) is that
> completely empty subroutines (that is subs which contain no statements
> at all) a
hi all
I'm not sure if this is the proper forum for reporting Test::More bugs, but
I know some of the interested parties are listening :)
use Test::More tests => 2;
is(undef,undef);
is_deeply([undef],[undef]);
# both of these should fail
is('',undef);# this fails
i
Fergal Daly wrote:
> There are patches in the archives for this and a couple of other bugs but
> they were submitted along with another change that wasn't acceptable so they
> were never applied. A search for is_deeply should find the patches and a
> long argument,
I found some stuff about is_de
> Actually, it seems that some of the patches were applied. The problem is
> that is_deeply() delegates to ->is_eq() for non deep arguments but handles
> it's own string comparison once you descend into the structure.
yes, I figured it was something like that - who hasn't been bitten by this
kin
>> I just ran into a similar "problem" in POE::Driver::SysRW. For
>> portability I have a couple lines similar to
>>
>> $! = 0 if $! == EAGAIN or $! == EWOULDBLOCK;
>>
>> EAGAIN and EWOULDBLOCK are identical on most systems. In fact, one is
>> usually defined in terms of the other. They dif
Michael G Schwern wrote:
> http://mungus.schwern.org/~schwern/src/Test-Simple-0.48_02.tar.gz
>
> A new alpha release of Test::Simple/More/Builder. You can consider this
> the 0.49 release candidate. Please let me know how it goes.
sorry it took me so long to get around to trying this...
the
hi all...
I've been working on something a bit and wanted to run it by people here to
see if folks think it's a project worthy of persuing. basically the below
bit from the README kinda sums it up for me - locally wrapping lots of
routines is getting quite tedious (specifically sockets at the mom
stevan little wrote:
> Geoff,
>
> This sounds like mock objects basically
> (http://www.mockobjects.com/FrontPage.html), although maybe on a
> smaller/more-directed scale.
hrmph. now that you mention it, yeah, it does. and there's already
Test::MockObject (which I've heard about but obviously
hi chromatic :)
given being pointed toward Test::MockObject::Extends last time I decided to
rework my tests to use it instead of a dozen local overrides. I immediately
ran into a little snag.
I want to override IO::Socket::INET so that a class calling it's constructor
will use my mocked object.
> my $mock = Test::MockObject->new('IO::Socket::INET');
>
> $mock->fake_new('IO::Socket::INET')
>->set_false('connected')
>->mock('error', sub { 'localerror' });
>
> the goal being that when my class calls IO::Socket::INET->new($args) that it
> fails, returning my error strin
> It's your understanding. You're not mocking the class as a whole.
> You're mocking an instance. If it helps, think of prototype-based
> programming, where you don't inherit from classes, you inherit from
> other objects and selectively override or add methods on the new
> objects.
hmm, ok, I
> The docs may be misleading, especially as there's code in
> Test::MockObject that really should live in something like
> Test::MockModule or Test::MockPackage, neither of which exist yet.
>
> The important point is that you always have to work with the object
> returned from Test::MockObject::E
hi all :)
Michael G Schwern wrote:
> http://mungus.schwern.org/~schwern/src/Test-Simple-0.48_02.tar.gz
>
> A new alpha release of Test::Simple/More/Builder. You can consider this
> the 0.49 release candidate. Please let me know how it goes.
just out of curiosity, what's the word on 0.49?
--Ge
hi paul :)
I think this has come up before, but I'm not sure what the resolution was.
I just came across (production) code that looks like this:
return 1 if $one == $two or return 0;
in the condition coverage the second return is always false, but I suppose
that it could be argued that if the
>>> return 1 if $one == $two or return 0;
>
>
> Just FYI:
>
> I always wonder why someone would write such code. IMHO this is
> unmaintainable code. I might not be an Perl expert, but I wouldn't consider
> myself a beginner either, especially not at boolean logic. And still, my
> mind canno
> You could use the values from Config.pm
paul and I were talking about this on irc, wondering if there was some
Config.pm value that would give the @INC that perl was compiled with.
neither of us could find one, and when I started poking around as to create
a patch, I fould that the logic the co
> 0.49 Thu Oct 14 21:58:50 EDT 2004
excellent! thank you very much.
for the interested, Test::More support has now officially been added to
Apache-Test server-side tests, provided you have 0.49.
kudos all around.
--Geoff
erver mode (httpd -X in Apache 1.X or
httpd -D ONE_PROCESS in 2.X) [Geoffrey Young]
In open_cmd, sanitize PATH instead of clearing it [Gozer]
Allow / \ and \\ path delimiters in SKIP file [Markus Wichitill
<[EMAIL PROTECTED]>]
Added an apxs query cache for improved test performance [Gozer]
ss runtime argument, which will start the server
in single-server mode (httpd -X in Apache 1.X or
httpd -D ONE_PROCESS in 2.X) [Geoffrey Young]
In open_cmd, sanitize PATH instead of clearing it [Gozer]
Allow / \ and \\ path delimiters in SKIP file [Markus Wichitill
<[EMAIL PROTECTED]>]
Add
Kevin Scaldeferri wrote:
>
> On Sep 21, 2004, at 1:30 PM, Kevin Scaldeferri wrote:
>
>>
>> So, I don't expect anyone to try to figure out this stack trace stuff,
>> but I'm curious if other people have seen stability problems like
>> this? Alternatively, if someone can tell me the exact logist
> if you haven't investigated Apache-Test yet, I would. our custom make
> target look like this:
I forgot to add some A-T specific stuff :)
t/conf/modperl_extra.pl:
if ($ENV{HARNESS_PERL_SWITCHES}) {
eval {
require Devel::Cover;
Devel::Cover->import('+ignore' => 't/response/'
Kevin Scaldeferri wrote:
>
> On Oct 2, 2004, at 12:36 PM, Geoffrey Young wrote:
>
>>>
>>
>> we use Apache-Test, which starts the server, runs the tests, and shuts
>> down
>> the server again.
>
>
>
> When I last talked with you about Apa
> [ Just before sending this I notice Geoff has recommended something
> better, but I'll send this too as another WTDI. ]
cool :)
I started to maintain Apache-Test skeletons, but I never quite got them up
to speed. give me a few days and I'll roll a tarball with a test-cover
target so that folk
Geoffrey Young wrote:
>>[ Just before sending this I notice Geoff has recommended something
>>better, but I'll send this too as another WTDI. ]
>
>
> cool :)
>
> I started to maintain Apache-Test skeletons, but I never quite got them up
> to speed. give me
David Wheeler wrote:
> On Oct 2, 2004, at 2:30 PM, Geoffrey Young wrote:
>
>> I started to maintain Apache-Test skeletons, but I never quite got
>> them up
>> to speed. give me a few days and I'll roll a tarball with a test-cover
>> target so that folks ca
>> - HARNESS_PERL_SWITCHES gets Devel::Cover started
>
>
> Module::Build's testcover target already does this.
:)
>
>> - +inc,$(HOME)/.apache-test keeps coverage away from generated A-T
>> files,
>> which isn't required
>
>
> Ah, cool. But $(HOME) doesn't correspond to ~/ here, does it?
>>test-cover ::
>> @cover -delete
>> @HARNESS_PERL_SWITCHES=-MDevel::Cover=+inc,$(HOME)/.apache-test
>>APACHE_TEST_EXTRA_ARGS=-one-process $(MAKE) test
>> @cover
>
>
> I wonder whether we shouldn't try to standardise the target name before
> it's too late to do so. Module::Build
David Wheeler wrote:
> On Oct 5, 2004, at 11:32 AM, Geoffrey Young wrote:
>
>>> Ah, cool. But $(HOME) doesn't correspond to ~/ here, does it?
>>
>>
>> yeah - it's equivalent to $ENV{HOME} in make-land. I guess there is
>> always
>> the dan
> +my $atdir = $self->localize_file_path("$ENV{HOME}/.apache-test");
> +local $Test::Harness::switches=
> +local $Test::Harness::Switches=
> +local $ENV{HARNESS_PERL_SWITCHES} = "-MDevel::Cover=+inc,'$atdir'";
somewhere in here it looks like -one-process is missing, though
David Wheeler wrote:
> On Oct 5, 2004, at 12:36 PM, Geoffrey Young wrote:
>
>> somewhere in here it looks like -one-process is missing, though I
>> wouldn't
>> know where it would go.
>
>
> I'll put it in, though it isn't needed if you use A-
David Wheeler wrote:
> On Oct 5, 2004, at 12:43 PM, Geoffrey Young wrote:
>
>> no, it is required. but only cvs currently supports -one-process as an
>> option - earlier versions will explode.
>
>
> Okay. So I just added this to the testcover
95 matches
Mail list logo
