On Nov 17, 2007, at 11:25 AM, Andy Dougherty via RT wrote:
I used something like
perl5.8 Configure.pl --cc=gcc --link=gcc --ld=gcc --ask
(the --ask is because I also changed the ccflags, ldflags, and libs to
match gcc, and the --ask version prompts with a default that is
almost,
but not quite, what I want.)
How wedded are you to the continued existence of the --ask option,
i.e., to the interactive mode in Parrot configuration?
While at the gym today, I realized that almost no matter what I did,
I would probably never be able to write tests of the configuration
steps which are robust enough to meet the situations you and
chromatic have described if users can change the direction of
configuration seven or more steps into the configuration process.
If, however, users were required to specify their variants as options
to Configure.pl, then I could adapt existing code such that:
perl5.8 Configure.pl --test --cc=gcc --link=gcc --ld=gcc ...
... makes all those options immediately available to the tests in t/
configure/ as well as to Configure.pl. The configuration tools tests
would then have available from the outset (a) all information
available from the Perl 5 Config, and (b) all information the user
wants/needs to specifically supply. This would have the following
consequences:
1) The test suite could be revised so that it more accurately
reflects the situation on the user's system.
2) The configuration system could be considerably simplified, as the
values determined in the current 'inter::' steps could either be set
in 'init::' steps or 'auto::' steps.
3) The test suite would be simplified, as many test files now exist
solely to test the '--ask' option in 'inter::' steps.
4) Since we could more accurately test our configuration tools
*before* actual configuration -- which, I have argued, is the right
time to do it, we could remove the 't/configure/*.t' tests from the
suite of tests run by 'make test'. Those Parrot developers working
on the configuration and build systems would have to run the pre- and
post-configuration tests, but other Parrot developers and language
porters would not.
5) We would be in a better position to move to particle's proposed
file-based configuration in the future. Command-line options,
interactive prompts and file-based configuration are all a way of
getting information from the user and stuffing it into the
Parrot::Configure object. Both command-line options and file-based
configuration supply Parrot::Configure::runsteps() with all the
information it needs before it starts running. The tests for
individual config steps which we have currently written would not
require adaptation to work with file-based configuration. Supplying
that information via interactive prompts, however, means supplying
information once Parrot::Configure::runsteps() has already started
running. The various situations there are too numerous to mock.
Going forward, I'm willing to maintain two ways of getting
information into the Parrot::Configure object -- but not three.
For the work I do on Parrot, I am constantly re-running
Configure.pl. On Linux I can get away with no command-line options
at all. On Darwin, I have to use some like --without-gdbm because of
the limitations of my iBook and some to get around a mistaken attempt
to build my own 'gcc'. (The latter options were taught to me by
chromatic and Coke. I wrap them in a shell script and *never* change
them.) So I have no use for interactive configuration steps
whatsoever. (Hey, I get frightened when I see interactive prompts
when installing CPAN modules!) I suspect that anyone who has to
reconfigure Parrot repeatedly can be persuaded to put all the options
up front. If that's the case, then we could scrap the interactive
mode -- and I could write much more robust tests!
So, how many people out there find that interactive prompts are
absolutely essential for configuring Parrot?
kid51
