On Sat, Jul 30, 2011 at 8:32 PM, Edward Z. Yang wrote:

This is supposed to get defined as a command line argument to the preprocessor, see compiler/main/DriverPipeline.hs.  Are you saying you don't see it when you run hsc2hs? Maybe someone else is calling a preprocessor but missing some of these arguments...

Yes, I don't see it when I run hsc2hs. I don't see how a define from ghc is going to make it into the hsc2hs generated C file, since it just compiles the c file with no special flags. Looking at the hsc2hs source, it runs the c compiler with cFlags, which I think ultimately comes from the flags. Since it doesn't import anything out of ghc I don't know how it's supposed to get macros from there either, unless that was supposed to have gone into some header. Here's my hsc2hs line: hsc2hs -v -c g++ --cflag -Wno-invalid-offsetof -I/Library/Frameworks/GHC.framework/Versions/7.0.3-x86_64/usr/lib/ghc-7.0.3/include \ -Ifltk -I. -I/usr/local/src/fltk-dev/fltk-1.3/ -D_THREAD_SAFE -D_REENTRANT -DMAC_OS_X_VERSION_MAX_ALLOWED=1060 -DMAC_OS_X_VERSION_MIN_REQUIRED=1050 Ui/Style.hsc Executing: g++ -c Ui/Style_hsc_make.c -o Ui/Style_hsc_make.o -Wno-invalid-offsetof -I/Library/Frameworks/GHC.framework/Versions/7.0.3-x86_64/usr/lib/ghc-7.0.3/include -Ifltk -I. -I/usr/local/src/fltk-dev/fltk-1.3/ Executing: g++ Ui/Style_hsc_make.o -o Ui/Style_hsc_make Executing: Ui/Style_hsc_make >Ui/Style.hs BTW, -Wno-invalid-offsetof was necessary to get the compiler to not complain about the C generated by the #poke and #peek macros, and with the latest version of hsc2hs I had to explicitly tell it where the ghc directory is... I guess it's supposed to get that out of its cabal but I'm not sure how.

On Sat, Jul 30, 2011 at 9:23 PM, Edward Z. Yang 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 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.

On 07/08/2011 02:18, Evan Laforge wrote:

...

On Sat, Jul 30, 2011 at 9:25 PM, Ian Lynagh 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.

So what's the consensus here? Does dropping all backwards compatibility from hsc2hs make sense? Presumably it's there for a reason so I may be missing something.

In any case, though I like the idea of dropping all the #ifdef, I think the specific instance for omitting #includes is incorrect, and I'm not sure why other people aren't seeing that.. I don't understand what's going on with __GLASGOW_HASKELL__. Maybe something funny with my install?

Should I try to send a patch for the remove all backward compatibility thing? Or one for the specific #include problem I've been having?

I've lost track of all the details here. But perhaps there's some historical cruft lying around because hsc2hs used to call GHC to compile its C files, and hence __GLASGOW_HASKELL__ would have been defined. In fact, the GHC build system passes --cflag=-D__GLASGOW_HASKELL__=<version> to hsc2hs when it runs it. Maybe Cabal should do the same. Does it? The problem with making the INCLUDE pragma conditional is that you can only do conditional pragmas using CPP, which requires the CPP extension, and moreover older versions of GHC did not support conditional compilation of pragmas (I forget which version added this, maybe 6.12). Cheers, Simon

On 09/08/2011 02:44, Evan Laforge wrote:

So the simplest thing to do is remove all the version stuff. That means that if you want to run hsc2hs with a version of ghc which is not the one linked in /usr/bin, you also can't run the hsc2hs linked in /usr/bin, but have to get the one out of the ghc directory. If no one has an objection to that then I'll try to make a patch with git and put it in a ticket.

The next simplest thing to do is to just document that anyone calling hsc2hs has to pass -D__GLASGOW_HASKELL_=version. I don't like this so much because it's error-prone, but doesn't require any code changes. So... remove it all? Yea / nay?

Yes, ok. Simon

On Tue, Aug 9, 2011 at 4:36 AM, Ian Lynagh wrote:

On Mon, Aug 08, 2011 at 06:44:29PM -0700, Evan Laforge wrote:

...

So... remove it all?

I've done so.

Yay, thanks!