It seems to me that the sensible thing to do is take the environment probing in two steps.
Step 1: We probe, and build a config file (not config.h, mind) with our results.
Step 2: We take the config file and build config.h and choose (or build) the right platform.h/platform.c file.
Step 3: We build the appropriate platform-specific library files, if there are any.
In a cross-compilation scenario, we'd skip step 1 and instead get handed a fully filled-in config file (So it'd be in our best interests to make it sane and easy to figure out) and skip the probing. It's also really handy to feed an old build's config file into a new build so the defaults feed forward.
The only problem I can forsee when doing cross-compilation is in the building of the library files. Parrot itself... no big. We build miniparrot for the platform you're on, then use the config file to rebuild for the target platform. That part works out OK, but the resulting full parrot won't be runnable on the platform you're actually on, to build the library files for the platform you want.
It's that library building that's the tricky bit, unless we want to use miniparrot to do all the library building. While that'll work, it'll likely be a bit limited. (Unless we do a three step deal -- build miniparrot, build parrot for your current platform, then use that parrot to build the parrot and library for your target platform)
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
