On 2/20/07, Aldo Calpini <[EMAIL PROTECTED]> wrote:
back in 2004, Dan Sugalski wrote:
http://www.nntp.perl.org/group/perl.perl6.internals/2004/09/msg25521.html
nowadays my effort of porting Parrot to the PocketPC platform, as you
may have suspected, force me to reopen the question.
there is, I know, a lot of work to be done. and this will surely require
a lot of time. and, very probably, much more knowledge than I currently
have. but I'm willing to learn, and to live long enough to complete the
task.
I intend to start submitting patches that do not break things that
already work. for example, everything that is pulled out from Perl's
%Config will need to be pulled out from somewhere else if, and _only
if_, we are currently cross-compiling. (well, this is the plan. I can't
exclude that something somewhere may break for some obscure reason, so
please bear with me in advance :-).
before I start dirting my hands with code, I'm here to ask you:
1) does anybody have objections to patching the current build system for
cross-compilation (even "yes, but not now because..." objections)?
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.
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.
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
