My problems running 'make' having been allayed, I've gotten back on
track in my work on refactoring and testing tools/build/pmc2c.pl. In an
earlier posting I reported that my first attempt at patches failed
because I had not understood that tests of some of the subroutines in
that program will give false positives if run after 'make' has run. I
opined that a test of a build tool such as pmc2c.pl is only valid when
the file structure under your top-level Parrot directory is that found
after Configure.pl has run but before 'make' has been called. Such a
test asks, in effect, "Will pmc2c.pl, called with option X and arguments
Y, be able to do what 'make' will call upon it to do?"
My further study of pmc2c.pl, however, suggests that that may be a too
strict formulation of the question. There may be subroutines in
pmc2c.pl whose functionality is intended for a point later in the build
process when 'make' has already been called.
Specifically, consider pmc2c.pl's subroutine print_tree(). The POD
states that it should be called like this:
print_tree( [$dir1, $dir2], 0, $file1, $file2, ... );
The POD then states that print_tree()'s purpose is to "[p]rint the
inheritence [sic] tree for each of the files, using the given
directories to search for all of correct PMCs." This doesn't tell us
*what kind of files* should be passed as arguments to print_tree().
Well, then, can we find any examples where print_tree() is called and
make guesses about what its arguments should be from looking at those
calls? The POD tells us that print_tree() is called when the '--tree'
option is supplied to pmc2c.pl.
Print a class tree for the specified PMCs:
% perl tools/build/pmc2c.pl --tree src/pmc/*.pmc
...
if ( $action{tree} ) {
print_tree( [EMAIL PROTECTED], 0, @ARGV );
}
But, AFAICT, 'make' never calls pmc2c.pl with the --tree option! So
print_tree() is never called during 'make'! (In this it differs from
pmc2c.pl subroutines such as dump_default() (the --vtable option),
dump_pmc() (the --dump option), and gen_c() (the --c option).)
Peering inside print_tree(), we find that it very quickly places a call
to the read_dump() subroutine
for my $file (@files) {
my $class = read_dump( $include, $file );
...
}
read_dump() only gives meaningful results when its $file argument is a
.dump file
sub read_dump {
my ( $include, $file ) = @_;
$file =~ s/\.\w+$/.dump/;
$file = find_file( $include, $file, 1 );
...
.dump files only exist once dump_pmc() has been called. So it seems
fair to conclude that the files passed to print_tree() as arguments
ought to be .dump files -- files which only exist after 'make' has
called for pmc2c.pl to execute with the --dump option.
If that is the case, then we would have to think of print_files() not as
something which is essential to the Parrot build process, but as a
diagnostic to examine the results of the 'make' stage of that process.
And if that is correct, then testing of print_files() has to proceed on
the assumption that it is being executed at a point in the build process
*different* from those other pmc2c.pl subroutines for which I have been
writing tests.
Is the above analysis correct? I would appreciate feedback, as the
answer will have a big impact on how I spend my Parrot test-writing time.
Thank you very much.
kid51
