Failures in 'make test', reproduced via 'prove -v'. Please see
attached.
> Failures in 'make test', reproduced via 'prove -v'. Please see
> attached.
Unfortunately I'm not seeing any test failures with these files on
linux x86 with r17914 (I believe yours is with r17912). I always get
a bit jumpy when I've just done some commits and things start failing,
so would it be possible for you to work out which revision builds and
tests properly for you to work out at which revision the errors
started occurring? I can back out my recent changes if they are at
fault.
Paul
I don't really know how to do that efficiently. I know that on March 28 I was running 'make
test' without these failures.
What's really perplexing is that I have *two* sandboxes on my disk, in one of which ('options')
I am getting the failures mentioned and in the other of which ('parrot') I am getting only the
failures in t/pmc/sub.t. (So let's hypothesize that the problem with t/pmc/sub.t is distinct
from the others' problem.) But both of these sandboxes have been 'svn update'-ed from
trunk before configuration, build and testing. I examined the 'myconfig' and 'lib/Parrot/
Config/Generated.pm' files for each sandbox and found no significant differences.
But I did find one significant difference. In the sandbox experiencing the failures, 'options/',
following configuration there are a total of 2949 files being created under the 't/' directory
which are *not* present in the more-or-less successful 'parrot/' sandbox (see attached
only.in.options.t.txt). In neither sandbox have I yet called 'make realclean'. So why would
2949 files be created in one sandbox but not another when both sandboxes are configured
the same and when both have been updated from trunk?
kid51
And the failing test in t/pmc/sub.t has bee TODO-ed.
Can anyone suggest why the name of one's sandbox directory should affect the test results?