Re: Config parameter files
Dan Sugalski [EMAIL PROTECTED] wrote: 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. Internally, Configure is a four-step process (initialization, interactive probing, automatic probing, generation); in principle, we could add something to initialization that loaded in a configuration database and skipped the probing steps for a cross-compile. The tricky part is that the probing steps and the generation steps are a bit incestuous, in that many of the probing steps insert parts of Makefiles into the configuration database, which are then interpolated in the Makefile generation steps and stripped out before the Perl and Parrot configuration modules are written. (Without their removal, the serialized database would be at least a few hundred kilobytes, and possibly more--early versions of config_lib.pasm would actually crash because either IMCC or Parrot itself couldn't handle the gigantic strings being thrown at it.) The Right Solution is to create a cleaner separation, but in practice people writing Configure steps have never done that, and I don't really hold much hope for them doing so in the future. Step 3: We build the appropriate platform-specific library files, if there are any. It occurs to me that most of these are bytecode or frozen PMC files, both of which are portable. So we could build them with a locally-available Parrot, then transfer them to the target platform. I don't think it's onerous to require that you have a full Parrot built on the source platform... -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker There is no cabal. [I currently have a couple Gmail invites--contact me if you're interested.]
Re: Config parameter files
Dan Sugalski wrote: 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) This is some weird step cousin of Canadian Cross [http://www.objsw.com/CrossGCC/FAQ-4.html#CanadianCross]. I think the three step version is required in order to get this right. You don't want to loose anything in the end libraries just to save some pain in the cross compilation. One expects the cross compilation to be mind-numbingly painful. As it is, it looks as cross-compiling parrot may be simpler than doing a canadian cross on gcc. We don't need to worry about compiling a complete suite of cross platform tools: once we have a VM and it's libraries, we are done. Gregory
Re: Config parameter files
At 12:03 PM -0700 9/8/04, Gregory Keeney wrote: Dan Sugalski wrote: 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) This is some weird step cousin of Canadian Cross [http://www.objsw.com/CrossGCC/FAQ-4.html#CanadianCross]. I think the three step version is required in order to get this right. You don't want to loose anything in the end libraries just to save some pain in the cross compilation. One expects the cross compilation to be mind-numbingly painful. As it is, it looks as cross-compiling parrot may be simpler than doing a canadian cross on gcc. We don't need to worry about compiling a complete suite of cross platform tools: once we have a VM and it's libraries, we are done. Hrm, this'd also argue that we really, really want to do alternate destinations for builds too. Besides being handy for places that want a single source tree compiled on multiple systems, it'd make the cross-compilation easier. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
