Trying to build CPAN modules, e.g. XML::Parser so that the XS
extensions end up as universal binaries on Mac OS X.
So what do I need to put in makepl_arg and mbuildpl_arg so that
LDFLAGS, OTHERLDFLAGS, CFLAGS, and
all get
-arch ppc -arch i386
and whatever else is needed?
And am I miss
On 1 Nov 2007, at 21:22, brian d foy wrote:
# t/controller.t
use Test::Steering;
include ('xt/frob') if frob_avail();
include ('xt/slow') if all_the_time_in_the_world();
That would happen at `make test` time (or whatever M::B does)?
That's what I envisaged, yes. The harness would run t/cont
On 1 Nov 2007, at 21:12, brian d foy wrote:
I hadn't been paying too close attention, but it looks like TSP might
be able to do the stuff I am doing with Test::Manifest. If TSP become
core, that would be really nice. :)
Well I'd like that - but it's not without controversy :)
--
Andy Armstro
In article <[EMAIL PROTECTED]>, Andy
Armstrong <[EMAIL PROTECTED]> wrote:
> On 1 Nov 2007, at 14:12, Michael Peters wrote:
>
>
> Yeah, but from the user's PoV this is pretty easy:
>
> # t/controller.t
> use Test::Steering;
>
> include ('xt/frob') if frob_avail();
> include ('xt/slow') if all_
In article <[EMAIL PROTECTED]>, Eric Wilhelm
<[EMAIL PROTECTED]> wrote:
> # from Andy Armstrong
> # on Wednesday 31 October 2007 16:51:
>
> >But what about a more general mechanism? A TAP directive that means
> >'schedule these other tests'. So then you'd have a controller test
> >which was t
In article <[EMAIL PROTECTED]>, Andy
Armstrong <[EMAIL PROTECTED]> wrote:
> We have this ticket in the Test::Harness RT queue:
>
> http://rt.cpan.org/Ticket/Display.html?id=29633
>
> Martin Thurn is asking for a SKIP_OUT directive that would skip all
> remaining test files and return a PASS.
# from Andy Armstrong
# on Thursday 01 November 2007 09:33:
>On 1 Nov 2007, at 15:44, A. Pagaltzis wrote:
>> * Andy Armstrong <[EMAIL PROTECTED]> [2007-11-01 15:50]:
>>> The config needs to be dynamic at test time - so it might as
>>> well be a script...
>> But it only needs to be dynamic in a min
On 1 Nov 2007, at 16:53, Geoffrey Young wrote:
anyway, its not the best way to handle things necessarily (I didn't
write it, and it's over 6 years old now :) but it it does come in
handy
every once in a while, so the idea in general is probably sound.
So that's another use case for TSP righ
On 1 Nov 2007, at 15:44, A. Pagaltzis wrote:
* Andy Armstrong <[EMAIL PROTECTED]> [2007-11-01 15:50]:
The config needs to be dynamic at test time - so it might as
well be a script that runs and outputs a description of which
tests to run, right?
But it only needs to be dynamic in a minority o
On 1 Nov 2007, at 15:38, Michael Peters wrote:
Isn't this the problem that SKIP was designed to fix? If it needs to
dynamically
determined if a test should run, isn't the test itself the best
place to do
that? xt tests shouldn't be run unless explicity done so by the
runner of the
tests (a
* Andy Armstrong <[EMAIL PROTECTED]> [2007-11-01 15:50]:
> The config needs to be dynamic at test time - so it might as
> well be a script that runs and outputs a description of which
> tests to run, right?
But it only needs to be dynamic in a minority of cases. So it
seems to me it should be the
Andy Armstrong wrote:
> On 1 Nov 2007, at 14:32, Michael Peters wrote:
>> But if they just do their own harness it becomes:
>>
>> push('xt/frob', @tests)if frob_avail();
>> push('xt/slow) if all_the_time_in_the_world();
>> Test::Harness::runtests(@tests);
>
>
> Yes, they could. But if you write y
On 1 Nov 2007, at 14:32, Michael Peters wrote:
But if they just do their own harness it becomes:
push('xt/frob', @tests)if frob_avail();
push('xt/slow) if all_the_time_in_the_world();
Test::Harness::runtests(@tests);
Yes, they could. But if you write your own harness you presumably
lose, e.
On 1 Nov 2007, at 14:31, A. Pagaltzis wrote:
This way they can have control over not only which files to
run, but which routines (if they're using Test::Class), etc,
etc.
… TAP encompasses scenarios where the notion of files and test
routines doesn’t even compute.
Yes - agree 100%. Hence it s
Andy Armstrong wrote:
> Yeah, but from the user's PoV this is pretty easy:
>
> # t/controller.t
> use Test::Steering;
>
> include ('xt/frob') if frob_avail();
> include ('xt/slow') if all_the_time_in_the_world();
But if they just do their own harness it becomes:
push('xt/frob', @tests)if frob_
* Michael Peters <[EMAIL PROTECTED]> [2007-11-01 15:15]:
> Sounds to me like it should just be a custom test harness. If
> the user needs to dynamically figure out which tests to run,
> then why not create a custom harness which will do what they
> need.
I was going to say the same. Then it occure
On 1 Nov 2007, at 14:12, Michael Peters wrote:
Andy Armstrong wrote:
Yeah - I slept on it. It should be TSP - Test Steering Protocol. If a
test emits TAP it's a test, if it emits TSP it's a controller. TAP
should stay pure.
Sounds to me like it should just be a custom test harness. If the
Andy Armstrong wrote:
> Yeah - I slept on it. It should be TSP - Test Steering Protocol. If a
> test emits TAP it's a test, if it emits TSP it's a controller. TAP
> should stay pure.
Sounds to me like it should just be a custom test harness. If the user needs to
dynamically figure out which tests
On 1 Nov 2007, at 08:19, Andy Armstrong wrote:
Yeah - I slept on it. It should be TSP - Test Steering Protocol. If a
test emits TAP it's a test, if it emits TSP it's a controller. TAP
should stay pure.
http://testanything.org/wiki/index.php/TSP_Test_Steering_Protocol
--
Andy Armstrong, Hexten
On 1 Nov 2007, at 00:11, Eric Wilhelm wrote:
But what about a more general mechanism? A TAP directive that means
'schedule these other tests'. So then you'd have a controller test
which was the only one directly visible to Test::Harness and that'd
decide which other tests to run.
It sounds like
20 matches
Mail list logo
