For perspective, keep in mind that we will eventually be refactoring the
Perl 5-based configure system anyway, to remove the dependency on an old
install of Perl 5. So, the behavior of the current prototype
configuration system is more important than the internal structure of
the code.
James E Keenan wrote:
The current Parrot configuration system is essentially a harness.
P::C::runsteps() will go from one step to the next regardless of whether
the first step completes successfully. So critical failures don't cause
configuration as a whole to abort.
But 'critical' is in the eye of the beholder.
Take configuration step #1, init::manifest, for example. Currently,
when it fails to locate all the files listed in the MANIFEST, it
complains -- or, more precisely, acks -- about missing files and then
allows config step #2 to begin. When this has happened to me, I tend to
make a mental note, I continue to hack on whatever I was doing, and then
resolve the question of the missing file before my next 'svn ci' and
'perl Configure.pl'. That's because I'm usually more interested in
what's happening in step #10 or #12 than I am in immediately correcting
step #1. But, as we saw recently, other dedicated Parrot developers may
feel that step #1 should cause the whole configuration process to come
to an immediate halt.
I would like to have the option of making some configuration failures
fatal. The lack of a working C compiler is a good example, but I imagine
we will find others as we go along.
I would also like the option of telling Configure to ignore failures
that would usually be fatal and carry on through the process. Getting a
full report of all failures is useful for automated smoke testing, or
other cases when the build is running in a scripted way rather than an
interactive way.
It seems we can have the best of both worlds if runstep() reports
success or failure, and the configuration harness (or a package variable
for each step) keeps track of which steps should be fatal.
So I think our alternatives are either:
(1) Retain the current system, in which the failure of one step does not
prevent Configure.pl from attempting the next step.
(2) Jettison the current system completely and require that each config
step demonstrate (say, by returning a true value rather than 'undef')
that it has completed successfully.
We would have to make some changes to the system, but changing the
return value from each step shouldn't be too dramatic.
(3) Have the Parrot leadership make an explicitly subjective judgment
that some config steps are more equal than others and allow them to have
a different interface (specifically, different return values) from all
the others.
A consistent interface is better.
On which are fatal, I'm happy to start with just the C compiler check,
and maybe the MANIFEST check, and then review the other steps on a
case-by-case.
It also means -- and here comes the place where I have major ego
investment -- that many of the step runstep() routines are difficult to
test thoroughly. Since June I have been writing tests for the
config/*/*.pm packages in the reconfigure/ branch and, as they have
matured, have brought them into trunk. But the fact that only about 13
of the 58 config steps are yet represented by tests in t/configure/ is
testimony to the difficulty in thoroughly testing many of them.
And I hate code that I cannot test thoroughly. (In fact, I'm going to
use it as an example of untestable and uncoverable code in my talk on
coverage analysis at Pittsburgh Perl Workshop next month.)
I'm in favor of a refactor (over time, not all right now) that changes
each runstep() routine into a very small routine that just calls other
routines.
I'm eager to work with other Parrot developers at planning for the
evolution of the configuration process (e.g., the file-based
configuration suggested by particle), but I think we should be cautious
about overhauling the current system and even more cautious about
allowing particular configuration steps to behave differently from others.
Agreed on not underestimating the value of working code, and that
consistency is important.
Allison
