This thread and RT ticket (41168) have been under way since Jan 03 2007 and I'm afraid that the discussion is collapsing under its own weight. May I make an attempt at summarizing the issues? Let's proceed from the outermost inwards.
1. Should the Parrot configuration process come to a halt if any one configuration step fails? Right now, Parrot::Configure::runsteps() works as a harness: If one step fails, it goes on to the next step. 2. Even if the failure of a configuration step typically does not stop configuration dead in its tracks, are there some configuration steps which are more important than others (e.g., inter::progs, with respect to its test for the presence of a C-compiler) which ought to stop configuration cold if they fail? 3. Let's assume that we grant inter::progs more importance than other configuration steps. How should the absence of a working C-compiler be detected and reported? 4. There are several Parrot::Configure::Step methods such as cc_gen(), cc_build() and cc_run(). Since these methods are essentially wrappers around system calls to C programs, how should failures in those underlying C programs be reported and passed through the configuration process? (Error codes? Messages?) 5. The Configure.pl command-line options do not have a consistent design. How should they be changed -- or should they be? (Allison has noted that this has already been discussed in a separate thread. That thread is http://rt.perl.org/rt3/Ticket/Display.html?id=42412, open since Apr 10, and that's where further discussion of this issue should take place.) Items 1 and 2 above imply an approach to configuration considerably different from the one we now follow -- differences which, I suspect, would entail the revision of a Parrot Design Document. If someone thinks we should have that discussion, that someone should open up a separate ticket to track that discussion. Let's skip over item 3 for a moment. Since the Parrot::Configure::Step methods mentioned in item 4 are used in many of the configuration steps, improving them would have wide benefits. I myself am not sure exactly how they should be improved, but I would recommend opening up a separate RT ticket for each of those methods as needed. Back to item 3. We never did resolve the question of detection of a working C-compiler. IMO, that's the question that we should continue to discuss in RT -- and the only issue that should continue to be discussed in this particular RT. And if we think that our current method of detecting a C-compiler is, if not perfect, good enough for the present, then I would recommend that Paul close the ticket. If you want to discuss the other issues mentioned above, I would recommend either going to the RTs already open or opening a new one. Thank you very much. kid51
