jerry gay ha scritto:
On 2/20/07, Aldo Calpini <[EMAIL PROTECTED]> wrote:
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.
that's all very good.
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)?
[...]
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?
I have no problems with this approach. modulo the fact that I'm an
absolute beginner in the fine art of version control (some CVS, a little
bit of SVN, but just basic checkout-checkin), so I have no idea how to
go about branching and merging and all that stuff. but I'll find the
time to RTFM on my own :-)
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.
yuck. shortly after I sent my message I stumbled upon
http://rt.perl.org/rt3/Public/Bug/Display.html?id=31136. and my first
thought was "oh, no".
having the build system done by a miniparrot isn't going to be
convenient for cross-compiling. right now, I successfully built parrot
tweaking the source here and there, but as I said in another message,
the next steps in the Makefile (building the core Parrot library and
finally installing the product) are going to be a huge pain.
cross-compiling a simple, standalone, test executable to check for
features, headers etc and running it on the target platform is, well,
easy enough. on the other hand, running something (the miniparrot) which
probably expects to have the whole build directory at hand, this isn't
easy. copying files to and from the target device and generally
exchanging data is slow, unsafe, and ultimately just a hack. add to this
that we're talking about PDAs, which are usually much slower and
severely resource-constrained (both in RAM and storage) than a regular
desktop.
for PocketPC's sake, using a miniparrot to do most of the build is a
malus, not a bonus.
but this wouldn't affect, for example, the Nokia N800 port, which uses
scratchbox as an environment. this, however, comes at a cost: you can
build for the N800 _only_ on a *nix host platform. probably developing
something like scratchbox for CeGCC would be the Right Thing To Do. but
that's a completely different story (and a completely different effort,
alas).
all in all, this is something that will need to be considered very
carefully. and I guess I've ranted enough about it now :-)
cheers,
Aldo
