| Subject: | Devel-PPPort breaks blead |
ppphtest.t is failing in Perl5 blead. Here is the relevant portion of
an email I sent p5p giving the result of my investigation into the cause:
The test that is failing in cpan/Devel-PPPort/t/ppphtest.t is related to
the files in this loop
for (qw(main.xs mod1.c mod2.c mod3.c mod4.c mod5.c)) {
They have all been put in a directory (with nothing else) and this
command run:
ppport.h --copy=f
This command analyzes the porting needs in each file in the directory,
and for each that has any such needs, to write out a changed file,
adding suffix 'f' to the name. mod5.c alone of the 6 files doesn't have
any porting needs, so shouldn't have any file written out for it.
The two tests in ppphtest.t that are failing check that:
1) the output of the command only does 5 writes
2) mod5.cf doesn't exist
The reason they are failing is that ppport.h is now deciding that mod5.c
does require porting changes, and so is writing out a changed version.
I looked at the code in ppphtest.t. There are two loops, one for
scanning in the files to be analyzed, and one to do the analysis. The
code is dense and uncommented, but what it looks like to me is that the
file code is kept temporarily in a hash entry that is global to all the
files, not file specific. Later, that entry is copied to a per-file
hash. When I add a print to see what that per-file code is, it is set
to the code of the final file scanned. This is causing the wrong code
to be generated for all but that final file.
Int ppphtest.t, the file names are placed in a hash and then written
into a directory in a
for (keys %hash) {}
loop. That means that now the files are created in that directory in
random order. ppport.h uses File::Find to parse the directory. I
suspect it returns things by inode order, so that suggests that the
files are getting scanned by ppport.h in random order.