On Sep 18, 2007, at 12:29 AM, Allison Randal wrote:
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.
I can think of two revisions which would be relatively simple to
implement and which would move us in the direction you suggest.
1. Analogous to our current Configure.pl option '--verbose-step=',
create an '--abort-step' option which permits the user to specify on
the command-line *one* configuration step whose failure should, in
that user's opinion, cause configuration as a whole fail. This would
be of benefit to a Parrot developer who is refactoring a particular
config step and wants immediate feedback on how the process works up
through that step. (Once we have a file-based configuration system
as an alternative to a command-line-option-based system, it will easy
to check off the config steps which you want as either --verbose-step
or --abort-step.)
2. The current configuration system is a harness, so let's make it
perform as a slightly better harness. Let's have it keep a simple
log of config steps which failed and then report those failures
instead of the current ever-cheery message from that use
Parrot::Configure::Messages::print_conclusion().
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.
The suggestions above would permit individual Parrot hackers to
experiment with having overall configuration fail based on the result
of one step. We could use reports on those experiments as data to
decide in the future whether to make particular steps always mandatory.
If these revisions seem reasonable I will open up RT tickets for each
tonight, then begin working on them, probably first in the
reconfigure/ branch before proposing for commit to trunk.
kid51
