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

Reply via email to