status of template haskell + cross compiling plans for 7.8?

Carter Schonwald carter.schonwald at gmail.com
Fri Jun 14 23:44:19 CEST 2013


Awesome! Please let us know how we can help get those into good shape for
being merged in!

That leaves the other question: how could we support the "Fat Binary"
builds for IOS devices?

I assume that this would only be supported via -fllvm, but work would be
needed to support such? Is it a tractable small project to deal with that,
or easy, or hard? (I'm not yet familiar enough with the relevant
engineering in GHC, but I understand this is important for folks who wish
to develop applications that target multiple IOS device variants, which
apparently use different ARM variants hand in hand with that!)

-Carter


On Fri, Jun 14, 2013 at 4:11 PM, Luite Stegeman <stegeman at gmail.com> wrote:

>
> We've had TH working in GHCJS [1] for a few months now, compiling once for
> the host platform, and once for the target.
>
> Our GHCJS GHC patch [2] (that we hope to get merged before 7.8) adds,
> among other things, WayCustom to the Ways in DynFlags, which just adds a
> custom token to the filename extension. This, uhm, way (sorry), we generate
> native files ".o" and ".hi", and ArchJavaScript files ".js_o" and ".js_hi"
> in the same directory. TH always uses the native files.
>
> We had to patch Cabal [3] to install the extra files (but we needed to
> patch Cabal anyway to add the GHCJS compiler flavour), but other than that
> it seems to work. GHC loads the native .a files when running TH, we do our
> own JavaScript linking.
>
> Another thing we patched is the GHC.Prim interface, which is different for
> 32 and 64 bit code. When we generate code for ArchJavaScript, we load a
> custom GHC.Prim for 32 bit, while we use the regular GHC.Prim when we
> generate the native code.
>
> It's all a bit hacky, but maybe this approach can be used as a basis for
> getting TH working in a real GHC. We could take some shortcuts to make a
> pseudo-mutltitarget compiler by just tacking an extra code generator onto a
> non-crosscompiling GHC. I'd be happy to help or discuss to make it more
> general.
>
> Luite
>
> [1] https://github.com/ghcjs / http://weblog.luite.com/wordpress/?p=14
> [2]
> https://github.com/ghcjs/ghcjs.github.com/blob/master/patches/ghc-ghcjs.patch
> [3]
> https://github.com/ghcjs/ghcjs.github.com/blob/master/patches/cabal-ghcjs.patch
>
> On Thu, Jun 13, 2013 at 11:43 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130614/c26a92ad/attachment.htm>


More information about the ghc-devs mailing list