#3472: Porting through .hc files broken
---------------------------------+------------------------------------------
Reporter: pumpkin | Type: bug
Status: closed | Priority: normal
Milestone: 6.12 branch | Component: Build System
Version: 6.12.1 RC1 | Resolution: fixed
Keywords: | Difficulty: Unknown
Os: Unknown/Multiple | Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Changes (by john435):
* status: new => closed
* resolution: => fixed
Comment:
Replying to [comment:5 ksf]:
> We either have to come up with a solution for using hsc2hs (take the
intermediate C files to the target and compile/run them?) or convert .hsc
files to autoconf + CPP (yeuch).
>
> It's quite straight-forward to split up the %.hsc->%.hs rule in two, the
first one generating %_hsc_make with a cross-compiler, the second one
moving the binary over to the target, executing it and piping the result
into %.hs. Compiling on the target is certainly feasible, too, but I
happen to have a working
[http://healthyweightlosspills.com/weight_loss_pills.html weight loss
pills] cross-compiler.
>
> I am, however, stuck with make, in the area of separating the build
directories into stage1/stage2 for the libraries as well as transferring
./configure output over from the target to the build platform, without
having that trigger recompilation of stage1 (and the package info being a
bit messed up wrt. -l flags, but that's a minor concern)
>
> Compiling the stage2 libraries with
[http://treatmentofmesothelioma.org/mesothelioma.html mesothelioma] actual
target info also opens up the issue that we can't use the native gcc as
it's quite likely to fail, not so much while compiling (at least .hc), but
linking: My linux doesn't come with libutil, for example. Both using a
cross-gcc and replacing gcc with touch should work, I've not had much time
to investigate this.
>
> The main issue, however, is that we're infecting perfectly cross-
platform .hc with platform-specific information by preprocessing Haskell
instead of C: It might be feasible to generate C stubs for all hsc2hs
macros and calling them via the ffi, leaving resolving of platform-
specific things until later. The whole build-process depending on .o s
being generated even when all you want to have are .hc s isn't helping
things.
>
> And then there's David's LLVM work... I'm currently slurping his thesis
because porting via LLVM looks very, very, elegant and painless, at least
from afar.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3472#comment:16>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
