Hi Folks, I don't think it's worth reviewing everything that's untidy about the current configure systems; it should be pretty obvious from looking at the code that it needs refactoring. This isn't a criticism of the original authors, just that the system has out grown it's roots as 'throw away' code. Since then 'the plan' has been clarified and we definitely will need some sort of configure system to run on top of miniparrot. There's no reason that configure system can't be written in p5 (but shipped as compiled PIR).
In addition to cleaning up the code for maintenance some features need to
be added:
- probes need to be able to cleanly bail out if they can't find a
requirement
- there needs to be some way of passing parameters into a probe.
For example, telling the gcc probe which version of gcc are
acceptable
I propose the following changes:
- The Configure::Data class gets lifted out of config/init/data.pl
and put into Parrot::Configure::Data.
- Parrot::Configure::Step is renamed to Parrot::Configure::Util (or
something).
- Parrot::Configure::Step becomes a very minimal base class for
other steps.
- Steps stay in the same file they are in now but have their
packages renamed to Parrot::Configure::Step::${type}::${name}.
(like: grep -lR 'package Configure::Step' config | grep -v .svn | xargs
perl -MFile::Basename -pi -e '$foo = basename($ARGV); $foo =~ s/\.pl$//;
$bar = basename dirname $ARGV; $_ =~
s/(?<!Parrot::)Configure::Step/Parrot::Configure::Step::${bar}::${foo}/;'
)
- Steps become 'plugins' that register their existence with
Parrot::Configure.
- Steps are required to define class methods called: description,
runstep, options (as in command line options), and result.
- Args are stored in the Parrot::Configure::Options namespace.
- It would be nice to shorten 'Parrot::Configure'. I'd like to
suggest changing the namespace to 'Peto' (Latin for seek).
An example of what you might put in a Configure.pl script.
--
my $conf = Parrot::Configure->new;
# Options are held as class data in the Parrot::Configure::Options
# namespace
$conf->options(%args);
# Setup a step to run and pass any extra parameters to that steps
# runstep
# method. Steps are (to begin with) run in the order they are
# specified. It # is a fatal error at this point if the step/plugin is
# registered.
$conf->step('cc', ...);
# The step method can be chained.
$conf->step('lex')->step('yacc');
# Steps can only be run once. Fatal error.
$conf->step('cc');
# Run all specified steps. Returns a Parrot::Configure::Data object.
$conf->run;
# Something that might be nice
# return a hash of step options => descriptions
$conf->step_options('cc');
--
As a long term goal I'd like to see Steps declare their dependencies on
other steps. So that you only have to declare which steps should be run
and not having to worry about ordering them to handle dependencies on
the results of previous steps.
Comments/Thoughts?
Cheers,
-J
--
pgpRvSfrbCrer.pgp
Description: PGP signature
