status of template haskell + cross compiling plans for 7.8?

[Alp Mestanogullari]

I recently came across this: https://github.com/neurocyte/ghc-android

The "build" script there together with the patches in the 'patch' directory
seem to take care of the issues mentioned on this thread. Of course, that's
quite a hacky way to make this work, but maybe Luite's work and this one
could inspire a good long-term solution.


On Wed, Jun 19, 2013 at 11:44 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> The issue that we hit sooner than this is that when we build a
> cross-compiler, we build all the libs for the target platform and not the
> host platform (see http://hackage.haskell.org/**
> trac/ghc/wiki/CrossCompilation<http://hackage.haskell.org/trac/ghc/wiki/CrossCompilation>
> **).  So to make TH work, we have to change the way we build cross
> compilers, and make the build system able to build and install two sets of
> libs.  This is probably a big job.
>
> I think it might be possible to avoid needing a multi-target GHC, as long
> as you have two identical GHCs, one that produces code for the host
> platform (host-GHC) and one for the target platform (cross-GHC).  You
> compile all the code once with host-GHC, and then again with the cross-GHC,
> the second time using the .o files produced by host-GHC to run the TH code.
>
> Cheers,
>         Simon
>
>
> On 17/06/13 14:52, Simon Peyton-Jones wrote:
>
>> I have not been following the details of this debate, but there is a
>> good reason why TH doesn’t work on a cross compiler. Specifically,
>> suppose module M imports module X, which defines a function mkD that M
>> calls in a splice, thus $(mkD “wobble”).
>>
>> Currently, we compile X to X.o, and when compiling M we dynamically link
>> X.o (and all the other libraries it relies on) into GHC so that we can
>> call foo.  Obviously X.o has to be runnable on the machine doing the
>> compiling, so if X.o is for some other architecture that’s not going to
>> work.
>>
>> There is no reason in principle why one could not compile X into
>> X.bytecode (along with all its dependencies), where X.bytecode is
>> architecture independent. Then X.bytecode could be interpreted on any
>> platform.  But GHC has no mechanism for doing this at all.   I’ve always
>> take the view that if you want X.bytecode, you may as well load X.hs and
>> translate it into bytecode.  A bit slower, to be sure, but maybe fast
>> enough.  But don’t forget those libraries.
>>
>> Anyway that’s the state of play.   Have fun!
>>
>> Simon
>>
>> *From:*ghc-devs-bounces@**haskell.org <ghc-devs-bounces at haskell.org>
>> [mailto:ghc-devs-bounces@**haskell.org <ghc-devs-bounces at haskell.org>]
>> *On Behalf Of *Carter Schonwald
>> *Sent:* 13 June 2013 22:44
>> *To:* ghc-devs at haskell.org
>> *Subject:* status of template haskell + cross compiling plans for 7.8?
>>
>>
>> Hey All,
>>
>> Whats the story planned for template haskell + cross compiler support
>> come ghc 7.8?
>>
>> I understand theres a lot of Template Haskell design underway, some of
>> which will help support tools like Manuel's Inline-Objective-C work.
>> Does this mean that factored out within this reorganization is a better
>> story for cross compilation?
>>
>> Especially since one kill "app" for the Inline-Objective-C template
>> haskell work would be writing IOS applications. Though I guess that also
>> touches on the need to sort out supporting "FAT" ARM binaries too, right?
>>
>> This intersects with a few different large subsets of tickets, so i'm
>> not sure if any single ticket is the right fora for this question.
>>
>> thanks!
>>
>> -Carter
>>
>>
>>
>> ______________________________**_________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/**mailman/listinfo/ghc-devs<http://www.haskell.org/mailman/listinfo/ghc-devs>
>>
>>
>
> ______________________________**_________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/**mailman/listinfo/ghc-devs<http://www.haskell.org/mailman/listinfo/ghc-devs>
>



-- 
Alp Mestanogullari
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130621/34ef6e83/attachment.htm>