On Wed, Sep 12, 2001 at 05:36:28PM -0500, David L. Nicol wrote:
> Jarkko Hietaniemi wrote:
>
> > The bootstrapping may take several rounds as Parrot learns
> ...
> > - execute (collect output) (note that execution may not be native)
>
> I don't think these two (cross-compile and build-own-tools) are
> strictly compatible goals.
>
> If you are going to build your own tools and use them, those
> tools will need to run in the local environment.
Huh? I do not follow. If you are going to run a native compiler from
your wrapper, you run the native compiler. If you are going to run a
cross-compiler from your wrapper, you run the cross-compiler. All I
was talking about was starting from the simple "shell" of
1. run the compiler
2. collect the results
3. do something with the results
and keep doing that iteratively.
> At some point a cross-compiler will be trusting its cross-compilation
> tool to run in the other environment.
Uhhh, no. "Host" platform where the tools like compiler, linker, etc
run produce executables for the "target" platform. How the executable
gets there and how it is executed, and what filesystem (if any...) it
sees, varies.
> Answering "what is a tool I will need to complete the process" and
> "what tools are part of the deliverable" could give a compilation
> procedure in which the intersection of the answers gets built twice.
>
> Testing non-native executables is tricky too. A protocol for
> how to do it, with either remote execution or emulation being
> easy to configure, would help. Emulators that pretend to be a
> remote hosts can make the second a special case of the first, but
> wrapping scripts can make a remote machine seem like a special case
> of an emulator just as easily.
See the cross-compilation support I put into the latest
(5.7.2 or later) Configures.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
