To summarize a bit of off-line correspondence with Allison and chromatic:
Allison wrote today:
"I can see why the [configuration step] object would be useful for
retrieving more information. In fact, the whole question of success,
failure, and whether the step should be fatal could be stored in the
configuration step object."
To which chromatic responded:
"It *could* be, but if I recall correctly, Jim says that nothing ever
uses it now. I suppose if we thought we might use it in the future, we
could make the object overload boolean checks so that you can get
true/false from it directly, but if nothing ever uses those objects now,
I don't see any harm in returning true/false directly."
I also responded:
"Here I disagree.
I think that the user (the human) should be able to determine how a
non-true value returned by a particular task's runstep() method should
affect the further progress of Configure.pl. I don't think that
fatality should be hard-coded into some steps and not others -- or into
any particular step.
"Take init::manifest for example. Gabor wanted a report of a file not
found in MANIFEST to cause all configuration to halt. I replied that
init::manifest was one step which currently handled failure well, i.e.,
it printed a reasonable error message and continued to the next step.
Which one of us is correct? It's a matter of user preference, so we
both are (or not).
"My recommendation is: Let the user decide in which tasks a non-true
return from runstep() should be treated as fatal. This will be
relatively easy for the user to decide once we have a '--fatal-step'
option or file-based configuration. (Default would be our current
behavior, augmented by a report at conclusion of Configure.pl which
lists tasks which returned non-true value.)"
And then Allison responded:
"Yes, certainly agreed. The user needs to be able to make all steps, and
individually selected steps, non-fatal (or fatal).
"But we were also talking about a way a step could indicate the severity
of its failure. Returning the configuration step object (or some other
status object) could be a way to do this. So, the check for a C compiler
could mark its failure as "severe" in the return object and the user
could indicate that they only want "severe" failures to be fatal,
instead of needing to flag each one individually.
[snip]
"And, as I said, this is a great place to start. So, for now just get
this working. I was jumping ahead to future possibilities.
"Anyway, aside from that one comment, the patch looks great. Thumbs up
from me."
All: In the next 2-1/2 weeks I have to concentrate on preparing my talk
for Pittsburgh Perl Workshop. So I may not get around to applying the
patch until then; we'll play it by ear. So you have time to add further
comments.
kid51
