Hi all,
I'm interested in implementing a general solution for TH during
cross-compilation, which if my naive lack-of-understanding is correct
will broadly involve the following three tasks:
1. Make the generation of byte code, or at least the subset needed for
useful TH use, target-independent
Simon Marlow writes:
> The right thing is to have a clean separation between runtime
> imports and compile-time imports. Perhaps we just annotate some imports to
> say they aren't needed at compile-time for running the TH code. but then
> we also need compile-time vs. runtime build-depends in o
Hi all,
I'm wondering, why do we require ghc to be bootstrappable with the past
2 major releases instead of just the past 1? Is it a common case that
someone is compiling GHC but can't easily get the latest release?
Thanks,
Shea
signature.asc
Description: PGP signature
_
Hi Simon, devs,
As part of my work to get TH working when cross-compiling to iOS, I've
developed remote-iserv [1] (not yet on hackage), a set of libraries for
letting GHC communicate with an external interpreter that may be on
another machine. So far, there are only three additions of note on top
No, as it currently exists it has to create a ProcessHandle, and I have
to layer some stuff on top of the iserv protocol anyway, so it wouldn't
really help much. I just use -pgmi to point to the client executable.
~Shea
Alan & Kim Zimmerman writes:
> As a matter of interest, are you making use
ules compiled with stage1 (the
> server). Is that a part of your plans? I think it would be a good cleanup.
>
> Cheers
> Simon
>
> On 14 January 2017 at 15:34, Shea Levy wrote:
>
>> Hi Simon, devs,
>>
>> As part of my work to get TH working when cross-compilin
What would you be able to achieve with this that you couldn't achieve
with branching in a fixed custom main function?
Thanks,
Shea
Harendra Kumar writes:
> Hi,
>
> GHC allows choosing a main function at link time using the "-main-is"
> option. I was wondering if there is a possibility to choose
