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