At 11:30 on 09/08/2004 CDT, Timm Murray <[EMAIL PROTECTED]> wrote:
>
> > *) Person building runs platform-specific script
>
> If that script is going to be platform-specific anyway, why not use Autoconf
> for the platforms that can handle it? You'd cover a rather large number of
> platforms that way, and the ones you don't are going to need their own script
> regardless.
It's very likely that the unix version of the platform specific script
WILL include some very minimal probing to do things like find the
compiler. But that's really all it needs to do- remember, the goal here
(as proposed) is to build miniparrot, not to build parrot. That means
you don't *need* autoconf.
The latter part of the build process, where we actually build the real
parrot, is a different issue. Dan's ruled out autoconf, so we get to
reinvent that wheel. FWIW, i'm not sure that I would have gone this
route, but dan's made a choice, and the best thing to do (IMHO) is to
follow that road and see where it leads. If it turns out to be dumb, we
move on. If it works, great.
So far, parrot's environmental probing needs really aren't terribly
sophisticated- most of the work has already been done in the current
Configure system- the test programs exist, and the mechanism to compile
and run them is well understood.
The remaining work to build the parrotconf system is mostly tedious rather
than complex. Some of the harder bits (IMHO) will revolve around
figuring out how to compile and link things, dynamic loading, and
architecture detection ($Config{archname}, osname, osvers, etc). If you
look at autoconf or metaconfig, those tasks are inevitably full of wacky
system-specific stuff. But since this is perl, porting metaconfig's units
for seting those variables to something that can run on parrot is probably
the way things will go.
It's not TERRIBLY hard but it isn't very glamorous either :) I did start
looking into converting the archname code into perl, as a starting point,
a while back. I may still have that somewhere and could probably finish
it up- my reasoning was that if I could get it from shell code into perl
code, i could understand it better and then rewrite it from scratch again
in some form that we could compile to PIR. Some sort of OOish language
with a working compiler for parrot would be nice. I'm not too keen on the
idea of maintaining nasty little probing code in assembly. :)
--Josh
