I've taken a look at using Module::Pluggable to register configure steps. The simplest way to do this is to let Module::Pluggable search through the ./config directory. This requires renaming all of the .pl configure files to .pm because of hardwired assumptions in Module::Pluggable.
This is a workable solution if there won't be a holy war over importing
Module::Pluggable into the Parrot tree. How do people feel about this?
This is what the step class hierarchy would look like:
--
$ perl -Ilib -MPeto::Step -le 'print join "\n", Peto::Step->steps' |
sort
config::auto::aio
config::auto::alignptrs
config::auto::antlr
config::auto::bc
config::auto::byteorder
config::auto::cgoto
config::auto::env
config::auto::format
config::auto::funcptr
config::auto::gc
config::auto::gcc
config::auto::gdbm
config::auto::gmp
config::auto::headers
config::auto::inline
config::auto::isreg
config::auto::jit
config::auto::m4
config::auto::memalign
config::auto::pack
config::auto::perldoc
config::auto::python
config::auto::signal
config::auto::sizes
config::auto::snprintf
config::gen::config_h
config::gen::config_pm
config::gen::core_pmcs
config::gen::cpu
config::gen::cpu::i386::auto
config::gen::cpu::x86_64::auto
config::gen::icu
config::gen::makefiles
config::gen::parrot_include
config::gen::platform
config::gen::revision
config::init::data
config::init::headers
config::init::hints
config::init::hints::aix
config::init::hints::cygwin
config::init::hints::darwin
config::init::hints::dec_osf
config::init::hints::freebsd
config::init::hints::hpux
config::init::hints::irix
config::init::hints::linux
config::init::hints::mswin32
config::init::hints::msys
config::init::hints::openbsd
config::init::hints::os2
config::init::hints::solaris
config::init::hints::vms
config::init::manifest
config::init::miniparrot
config::init::optimize
config::inter::charset
config::inter::encoding
config::inter::exp
config::inter::lex
config::inter::ops
config::inter::pmc
config::inter::progs
config::inter::shlibs
config::inter::types
config::inter::yacc
--
-J
--
On Wed, Nov 02, 2005 at 09:31:05PM -1000, Joshua Hoblitt wrote:
> 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
>
> --
pgpTG2IwxHoOx.pgp
Description: PGP signature
