Re: Cross-compiling Guile 2.0

[Andy Wingo]

So!

On Mon 21 Mar 2011 21:42, Andy Wingo <address@hidden> writes:

> On Mon 21 Mar 2011 20:58, address@hidden (Ludovic Courtès) writes:
>
>> At some point there will have to be a triplet → arch → endianness
>> conversion.
>
> Indeed.
>
>>  I’d rather have that conversion occur as close to the UI as
>> possible—i.e., close to ‘scripts/compile.scm’—rather than deep down in
>> (system base compile) because the triplet string is really a UI notion IMO.
>
> Actually I think it's more fundamental than that.  The compilation
> process tries, generically, to find a path through the language tower
> path from the source language to the target language.  There is nothing
> bytecode-specific in (scripts compile), except for a couple default
> target languages.
>
> It seems to me that the value of the target-type fluid at the time that
> `compile-passes' is called should be what determines the compilation
> path and target-specific settings.  For example, to continue the ARM
> compilation example, perhaps it would cause a different target language
> to be selected.
>
> Dunno.  All of that could just be too complicated, and maybe you are
> right.

To re-take this topic...  I looked at this, and had a patch that looked
for a #:target-endianness option in the compile options.  I'm fairly
sure that it does the bytecode compilation OK, but then to write the
objcode out to disk we need to attach the right cookie on the beginning
(word size and endianness), and we don't have the #:target-endianness at
that point.

After having read "Using System Type" again in the autoconf manual, I am
convinced again that the right thing to do is to add a %target-type
fluid or mutable parameter, defaulting to the %host-type.  We select how
to compile for the target by making decisions based on %target-type.
Since in Guile those decisions don't currently need to be made anywhere
except in compile-bytecode.scm and in bytecode->objcode in objcodes.c,
this is easy.  In the future when the %target-type could select an
entirely different assembler et al, the "where" of the decisions could
be moved somewhat; but I think that the mechanism sounds right to me.

Let me know if you have objections.  Thanks!

Andy
-- 
http://wingolog.org/