Hi!
Andy Wingo skribas:
> On Sun 29 May 2011 20:10, Andy Wingo writes:
>
>> On Fri 27 May 2011 16:51, l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Sounds good, but you’d need additional data that maps triplets (well,
>>> $host_cpu) to low-level info such as endianness and word size, right?
>>
On Sun 29 May 2011 20:10, Andy Wingo writes:
> On Fri 27 May 2011 16:51, l...@gnu.org (Ludovic Courtès) writes:
>
>> Sounds good, but you’d need additional data that maps triplets (well,
>> $host_cpu) to low-level info such as endianness and word size, right?
>
> Yes, which caused me a bit of ago
Hi :)
On Fri 27 May 2011 16:51, l...@gnu.org (Ludovic Courtès) writes:
> Andy Wingo skribas:
>
>> 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
Hello!
Andy Wingo skribas:
> 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 b
So!
On Mon 21 Mar 2011 21:42, Andy Wingo writes:
> On Mon 21 Mar 2011 20:58, l...@gnu.org (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.
On Mon 21 Mar 2011 20:58, l...@gnu.org (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
> (sy
Hello!
Andy Wingo writes:
> On Sun 20 Mar 2011 22:31, l...@gnu.org (Ludovic Courtès) writes:
[...]
>> Thus ‘%target-type’ would be inappropriate IMO because the target could
>> be chosen at run-time and it could be anything.
>>
>> ‘guile-tools compile --target=TRIPLET’ would be fine with me.
>
On Sun 20 Mar 2011 22:31, l...@gnu.org (Ludovic Courtès) writes:
> What I meant to say here, is that via a couple of knobs akin to
> ‘current-target-endianness’, you could actually cross-build for any
> target.
Yes, provided you have the compiler of course.
> Thus ‘%target-type’ would be inappro
Hi!
Andy Wingo writes:
> On Sun 20 Mar 2011 14:50, l...@gnu.org (Ludovic Courtès) writes:
[...]
>> However, I don’t think defining ‘%target-type’ would make sense
>> since:
>>
>> 1. Of the GNU triplet, only the $target_arch matters for bytecode;
>>
>> 2. You can really choose at run-time w
Hi :)
On Sun 20 Mar 2011 14:50, l...@gnu.org (Ludovic Courtès) writes:
> There’s already ‘%host-type’.
Ah, cool.
> However, I don’t think defining ‘%target-type’ would make sense
> since:
>
> 1. Of the GNU triplet, only the $target_arch matters for bytecode;
>
> 2. You can really choose at
Hello!
Andy Wingo writes:
> It's true that a simple command-line argument and fluid could work, but
> the situation will get more complicated, so we will need some part of
> Guile to define the host and target triplets. That's the questions I
> was really asking: where in Guile to define those?
On Fri 18 Mar 2011 11:17, l...@gnu.org (Ludovic Courtès) writes:
> I would add a ‘current-bytecode-endianness’ fluid in (language assembly
> compile-bytecode). The ‘compile’ procedure would have an optional
> ‘endianness’ parameter, which would set this fluid. And ‘guile-tools
> compile’ would h
Hello Andy!
Andy Wingo writes:
> On Sun 06 Mar 2011 23:12, l...@gnu.org (Ludovic Courtès) writes:
>
>> Neil Jerram writes:
>>
>>> In principle, how should Guile 2.0 be cross-compiled? I'm thinking
>>> mostly of the part of the build that compiles all the installed modules.
>>
>> Guile 2.0 can
On Sun 06 Mar 2011 23:12, l...@gnu.org (Ludovic Courtès) writes:
> Neil Jerram writes:
>
>> In principle, how should Guile 2.0 be cross-compiled? I'm thinking
>> mostly of the part of the build that compiles all the installed modules.
>
> Guile 2.0 can only be cross-compiled when the endianness
Neil Jerram schreef op za 05-03-2011 om 19:47 [+]:
> In principle, how should Guile 2.0 be cross-compiled?
We're using GUB -- http://lilypond.org/gub and are
sucessfully cross-building guile-2.0. You may want
to look at some patches
https://github.com/janneke/gub/tree/guile-2.0/patches
Hi,
On Sun 06 Mar 2011 12:03, Neil Jerram writes:
> What architectural dependencies are there in the .go format?
Only endianness and word size.
Of course a macro could check something about the system at
expansion-time, for example a value in a header; and there are things
like the mapping of
Hi Neil,
Neil Jerram writes:
> In principle, how should Guile 2.0 be cross-compiled? I'm thinking
> mostly of the part of the build that compiles all the installed modules.
Guile 2.0 can only be cross-compiled when the endianness and word size
of the host and target match (because the bytecode
Andy Wingo writes:
> On Sat 05 Mar 2011 20:47, Neil Jerram writes:
>
>> In principle, how should Guile 2.0 be cross-compiled? I'm thinking
>> mostly of the part of the build that compiles all the installed
>> modules.
>
> I have never cross-compiled anything, so I really don't know.
>
> Ideally
On Sat 05 Mar 2011 20:47, Neil Jerram writes:
> In principle, how should Guile 2.0 be cross-compiled? I'm thinking
> mostly of the part of the build that compiles all the installed
> modules.
I have never cross-compiled anything, so I really don't know.
Ideally we could make a cross-compiling
In principle, how should Guile 2.0 be cross-compiled? I'm thinking
mostly of the part of the build that compiles all the installed modules.
I think target emulation is needed, using QEMU, and in particular that
it wouldn't work to set GUILE_FOR_BUILD to a build-system-native guile,
because that w
20 matches
Mail list logo
