Re: hsc2hs and #include
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs and #include
On Mon, Aug 08, 2011 at 06:44:29PM -0700, Evan Laforge wrote: So... remove it all? I've done so. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs and #include
On Tue, Aug 9, 2011 at 4:36 AM, Ian Lynagh ig...@earth.li wrote: On Mon, Aug 08, 2011 at 06:44:29PM -0700, Evan Laforge wrote: So... remove it all? I've done so. Yay, thanks! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs and #include
On 07/08/2011 02:18, Evan Laforge wrote: On Sat, Jul 30, 2011 at 9:25 PM, Ian Lynaghig...@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. 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs and #include
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. Ahh, that could be the explanation. Perhaps it's been continued just because someone was making incremental updates and never realized the original reason the macro worked. 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? I don't know, but I'm not using cabal. 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). Right, but unless I'm mistaken, the CPP never goes into haskell, it goes into the generated C. 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? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs and #include
On Sat, Jul 30, 2011 at 9:25 PM, Ian Lynagh ig...@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. 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? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
hsc2hs and #include
So when I upgrade from 6.10 to 6.12 a LONG time ago, there was a bug
where hsc2hs would emit INCLUDE pragmas and ghc didn't like that. So
I hacked around it with an extra grep -v step in the Makefile. I
always meant to go fix it for real in hsc2hs and finally I came back
to that TODO item. I took a look at the hsc2hs source, and discovered
it's surrounding the INCLUDE line with
#elif __GLASGOW_HASKELL__ 610
However, that macro is never defined for me, so it always emits the
bogus INCLUDE line. I can't find anywhere that defines that macro,
but there is a lot of __GLASGOW_HASKELL So I modified
utils/hsc2hs/C.hs from
...
#elif __GLASGOW_HASKELL__ 610\n++
printf (\{-# INCLUDE %s #-}\\n\, \++
showCString s++\);\n++
#endif\n
to
#elif __GLASGOW_HASKELL__ __GLASGOW_HASKELL__ 610\n++
printf (\{-# INCLUDE %s #-}\\n\, \++
showCString s++\);\n++
#endif\n
And my problem is solved. Is this the correct solution? Where is
that macro defined?
I don't know how to mail patches with git, but anyway it's trivial so
I don't think it's needed :)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs and #include
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... Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs and #include
On Sat, Jul 30, 2011 at 8:32 PM, Edward Z. Yang ezy...@mit.edu 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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs and #include
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, at least for me, I don't see #INCLUDE pragmas output at all, with latest hsc2hs (old versions just didn't output any ifdefs, so we'd hit the problem.) 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). Cheers, Edward Excerpts from Evan Laforge's message of Sat Jul 30 17:10:21 -0400 2011: On Sat, Jul 30, 2011 at 8:32 PM, Edward Z. Yang ezy...@mit.edu 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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs and #include
On Sat, Jul 30, 2011 at 09:10:21PM +, Evan Laforge wrote: On Sat, Jul 30, 2011 at 8:32 PM, Edward Z. Yang ezy...@mit.edu 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. I think the right thing to do would be to have all the #if __GLASGOW_HASKELL__ ... lines be printf'd by the C program, so they end up in the generated Haskell file. 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? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs and #include
On Sat, Jul 30, 2011 at 9:23 PM, Edward Z. Yang ezy...@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 ig...@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.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
