On Feb 20, 2007, at 8:44 AM, jerry gay wrote:
On 2/20/07, Aldo Calpini <[EMAIL PROTECTED]> wrote:
no objection here! this is a long-desired feature, and is currently
unavailable. although i don't have a pocketpc to test on, i'll do my
best to help. for years, the dependence on perl 5's configure probes
has bothered me--just not enough to fix it. i'm glad to see this
porting effort will renew that effort.
Using perl 5's configure probes also somewhat limits us to how the
vendor distributed perl. It should also be considered that we can't
rely on perl5 being available, especially since we intend to replace it
eventually, so rewriting all the perl to support cross compiling would
likely not be the best thing.
2) does anybody already have a .plan or something in mind about it (so
that I may either learn from what others have thought, or avoiding
reinventing some wheel)?
parrot's configure system is *large*. and it's *working* (at least,
for the core platforms, most of the time.) that said, it's still
buggy, and we get reports of configure failures here and there. so,
changes to configure will affect everybody, and must be well tested.
therefore, i suggest a test-driven development style for configure
changes. first, we need higher test coverage on configure system. i'm
willing to organize a day or two to direct our efforts at testing the
configure system in order to get the work done quickly so your efforts
are not held up too long. once we have high-enough coverage, we can
begin refactoring with considerably more peace of mind than in the
current situation.
If we create a new configure system, we can essentially have two
configuration methods in the trunk, and have tests for the new one to
be sure it's working and portable before trying to get everyone to
start using it.
also, we need to smoke configure tests on multiple platforms. i
suggest initially you make your changes in a 'porting' branch, and we
merge the branch to trunk and smoke it in planned intervals. that way,
you get to make small, frequent commits to your branch, and rolling
back trunk changes is a simple command as well. also, we won't have to
modify our smokers to sometimes build a branch, they can keep running
against trunk.
since this style hasn't been practiced as a rule in the past, it'll
take some time to get used to--for all of us. but i believe it's the
safest way to proceed to modify the critical-yet-undertested subsystem
that is configure. are you willing to work in the way i described? how
does the project team feel about this approach?
speaking briefly about a technical plan--there have been discussions
of a way forward in the past. the general consensus is that miniparrot
be designed to be ANSI C-only, with as few platform-specific
extensions as possible, and zero dependence on perl's configure. after
miniparrot is built, it can be used to perform the remainder of the
build tasks in a portable manner. this gives us a lot of code reuse,
and should make future porting efforts easier. however, there's a lot
of this design left to flesh out, and none of it is implemented. i
think this is the right design, but we need to find one or more ways
to get there, and work towards that. however that discussion merits
one or more separate message threads.
~jerry
I've noticed a lot that mentions miniparrot being used for building
parrot, but at the same time, we don't have anything to work with to
know just how limited miniparrot should be. Perhaps a step to work for
before rebuilding the configure subsystem(which theoretically should be
in pir to get rid of perl5 dependence), is to get an actual miniparrot
working? Currently miniparrot just seems to be a macroparrot with a
miniconfig. If we can't realistically get a miniparrot, maybe it
should be considered if building a miniparrot for configuration is a
good idea. Instead of rewriting everything now in perl5 to support
cross compiling, maybe we should dive in and try to see if we can get
it rewritten in pir. After all, we're getting more pir programmers
than perl5 programmers it seems.
