#3472: Porting through .hc files broken
---------------------------------+------------------------------------------
Reporter: pumpkin | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.12 branch
Component: Build System | Version: 6.12.1 RC1
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: Unknown/Multiple
Architecture: Unknown/Multiple |
---------------------------------+------------------------------------------
Comment (by 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 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 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:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
