James E Keenan wrote:
Since November I've been working on maintaining those of Parrot's
configuration and build tools written in Perl 5. Lately I've been
trying to recruit others to help in that process. The discussion in
this thread suggests that at some future point some or all of the Perl
scripts/modules I've been working on will be replaced with ... something
else.
This has been the plan all along. Unfortunately it's not documented in
detail anywhere, but it has appeared in multiple mailing list
discussions over the years.
<http://www.nntp.perl.org/group/perl.perl6.internals/2007/02/msg36493.html>
<http://www.nntp.perl.org/group/perl.perl6.internals/2007/02/msg36593.html>
We can't depend on Perl 5 because we're replacing it.
This, of course, makes me wonder what I'm doing now and, more
importantly, makes me wonder what to say to other people with Perl 5
skills who want to help with the Parrot project.
Agile development in action. We can't know the full set of requirements
for the build system until we have a working build system. And we can't
delay all development waiting for the perfect build system. So we work
in stages of refinement. Your work here is enormously helpful.
This is not simply an ego thing on my part. I've written very little of
the Perl 5 tools and taken on maintenance of a bit more, but one thing I
realize is how much of Parrot's source code is written in Perl 5. How
much of that must eventually be replaced?
How much needs to be replaced depends on the strategy we take. One
possibility is to take some of the core pieces, make any minor
modifications needed to run on Parrot's implementation of Perl 5, ship
them as compiled bytecode, and run them on miniparrot. There are
advantages and disadvantages to a bootstrapping strategy like this, it
will work for some parts of the build system but not for others.
Some parts of the build system can be run on the maintainer side rather
than the user side. So, the release manager and developers can have a
dependency on Perl 5, while the end users get pre-generated C files and
so avoid the dependency. (Similar to the current strategy for IMCC where
individual users of Parrot don't need lex and yacc.)
Some parts may be written in PIR (again, only those parts that are late
enough to have a working miniparrot).
And who is going to maintain it? In my experience Perl 5 programmers
are relatively abundant while C programmers (these days) are rarer. How
many people might actually learn the yet-to-be-designed HLL that would
presumably replace a lot of the Perl 5 we currently use?
Agreed, we don't want to write an entire build system in C. It's a
horrible language for the kinds of dynamic effects we need in the build
system. Some parts will be in C, but just enough to get miniparrot started.
So, can someone draw a roadmap of:
-- *which parts* of Parrot's configuration and build tools *need* to be
replaced with something else;
-- *why* that replacement is necessary;
-- *when* in the design process that replacement must take place; and
-- *how* that replacement will be maintained going forward from there?
The biggest thing we need to start this roadmap is documentation on the
current configuration and build system. The current requirements and
process for building Parrot are the starting point for all future
refinements to the build system. You're in a better position to draft
that than anyone else in the project right now. Interested?
Allison
