hsc2hs and #include

[Evan Laforge]

On Sat, Jul 30, 2011 at 9:23 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> No, I don't think this diagnosis is correct.  hsc2hs is outputting preprocessor
> directives into hs files that GHC will then process.  Inspect your .hs file,

Not for me it's not, it's putting preprocessor directives into a C
file that the C compiler will then process.  Unless I'm getting
quoting levels mixed up, outInclude from C.hs is printing C code, with
a printf inside.  And when I run with --no-compile I see the ifdefs in
the C.  They won't work in haskell anyway unless you pass {-# LANGUAGE
CPP #-} and if hsc2hs is capable of emitting that pragma I can't find
where it does it.

> Actually, we should check if this problem is actually still around.
> Remember you need to use ghc-7.0.3's hsc2hs, not an arbitrary one lying
> around (though  it may work).

I was, now I'm actually using the one from HEAD, so I can mess with
it.  In any case, both report their version as 0.67.

On Sat, Jul 30, 2011 at 9:25 PM, Ian Lynagh <igloo at earth.li> wrote:
> But I also think we may as well just remove most of these conditionals.
> The GHC < 4.09 tests can surely be removed, and likewise the GHC < 6.3
> tests. Personally I'd remove the GHC < 6.10 test too, but perhaps that
> will be more contentious.
>
> Any opinions?

That was going to be my first suggestion.  Maybe the only reason these
are needed is that the hsc2hs binary itself isn't versioned, otherwise
you simply run the one that came with your ghc, and if it's for ghc-4
then it should be producing code ghc-4 understands.

So the problem would be with code that knows to specifically invoke an
older ghc, but still picks up the hsc2hs symlink which points to a
newer one.  I don't know of any framework for compiling with multiple
versions, but I'd think it should be smart enough to find the
appropriate ghc lib directory and run the various utilities out of
there.