Andy,
I think you are misunderstanding me.
On Apr 22, 2005, at 2:57 PM, Andy Dougherty wrote:
Yes it would, but it would be a tool only used for release (if at all). And
Pugs common practice it to mask all failures in the release.
Not exactly (again, assuming I understand this all correctly). It's been
common practice to mask all *expected* failures (though the extent to
which one ought to appeal to "historical" practice in Pugs is a bit
unclear to me ...).
For each CPAN release, we have masked *all* failures. This is to avoid needless bug reports for errors we know exist. Originally this was done by hand (yuk), then by script (not as bad, but still tedious and ugly), then we started using the t/force_todo file, etc etc etc.
Then once the tarball was made and put onto CPAN, we would usually then un-TODO-ed all the tests again, so that we had our expected failures.
I agree that globally masking failures is a bad thing, and to be honest I think that the per-file force_todo() will be the best way to go.
Stevan
My question is about *unexpected* failures. Do you really want to mask them too? If so, why not simply disable the 'make test' target in the release?
Here's a scenario I have in mind: If I ever successfully bootstrap
ghc-6.4, then I'll try to run Pugs. In my experience, trying things on
new platforms often yields surprises. Things like processor wordsize and
endianness, alignment constraints, different underlying C libraries, etc.,
are the sorts of things worth testing for. Masking any such failures would
seem counterproductive to the whole point of trying to get Pugs running on
a new architecture in the first place.
-- Andy Dougherty [EMAIL PROTECTED]
