cross-compile configuration

[allison]

Extend or modify the configuration system to allow cross-compilation. Requires decoupling Parrot configuration from existing configuration values in the system install of Perl, and providing a way to manually set compilation options.

[ahlgren]

Do I understand this ticket correctly, as it would then allow compiling any Parrot-compatible language A into a Parrot-compatible language B?

[bacek]

Replying to ahlgren:

Do I understand this ticket correctly, as it would then allow compiling any Parrot-compatible language A into a Parrot-compatible language B?

No, it's about compiling parrot by it self on platform A for platform B.

-- Bacek

[jkeenan]

Replying to allison:

> Requires decoupling Parrot configuration from existing configuration 
> values in the system install of Perl,

We know that this is a problem of long-standing and and providing a way to manually set compilation options. It is explicitly tracked in TT #619 and also touched upon in TT #855 and TT #1044.

Setting aside that (big) problem

... and providing a way to manually set compilation options.

We've had file-based configuration available (perldoc Configure.pl) for several years now. What else might we need to reach the objective of this ticket.

Thank you very much.

kid51

[jkeenan]

Replying to jkeenan:

We've had file-based configuration available (perldoc Configure.pl) for several years now. What else might we need to reach the objective of this ticket.

Perhaps I should have put that in the form of a question: What else might we need to reach the objective of this ticket?

kid51

[darbelo]

Replying to jkeenan:

We've had file-based configuration available (perldoc Configure.pl) for several years now. What else might we need to reach the objective of this ticket.

Perhaps I should have put that in the form of a question: What else might we need to reach the objective of this ticket?

IIRC, from my experimentation with this last year, file based configuration proved to be sufficient to start building parrot, the problem is that this only concerns the parts of parrot that are written in C. We can cross-compile those fine, mostly, but then we run into build steps that attempt to run code that has just been built (like, say, the miniparrot executable) for a different architecture, with predictable failure. My guess is that the Configure side of things is fine as is, and the remaining issues should be adressed in the build process proper.

[dukeleto]

May I suggest that we cheat a little and use qemu attain the goal of what we want from cross-compiling, without actually cross-compiling.

I stole this idea from how emacs is cross-compiled in OpenEmbedded. Here is the rough idea:

1) We add some arguments to Configure.pl to specify a target architechture 2) Our config subsystem learns how to detect if qemu is available 3) If qemu isn't available, die if attempting to cross compile 4) If qemu is available, start a qemu process of the wanted target architecture, then run the entire build process within qemu

The output of this will be binaries for architecture X, which are actually compiled, through the magic unicorn farts of qemu, for architecture Y.

I think that this is actually feasible in the short term, unlike *actually* modifying our config+build system to natively cross-compile, which I highly doubt will happen before the heat death of the universe.

[dukeleto]

To clarify, after qemu is started, another run of Configure.pl inside of qemu will be needed, and then a build. This wasn't clear from my previous comment.

[dukeleto]

 https://github.com/parrot/parrot/issues/173