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 <[email protected]> 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 < > [email protected]> 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 >> [email protected] >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
