hsc2hs and HsFFI.h

[Sigbjorn Finne]

Hi Ian,

it may encompass some of your suggested approaches below, but have
you considered either:

 - add "--print-hsc-options" to the GHC driver, which is akin to
   "--print-libdir". A ghc-installed hsc2hs shell wrapper or as you
   suggest have 'hsc2hs' probe the compiler it is using would then
   build on this.

 - have the GHC driver handle .hsc input by invoking 'hsc2hs' with the
    necessary local context.

I can see the value of not doing the latter (it already handles too many
kinds of input files) and would add to GHC's workload. But thought
I'd put it on the table at least..

Q: is the information that --print-libdir returns available programmatically
to Haskell code?

--sigbjorn

Ian Lynagh wrote:
> Hi all,
>
> Currently, hsc2hs (as shipped with GHC) cannot be used with just
>     hsc2hs Foo.hsc
> as it cannot find HsFFI.h (http://hackage.haskell.org/trac/ghc/ticket/2897).
> To make it work you need to run something like
>     hsc2hs -I /usr/lib/ghc-6.10.1/include Foo.hsc
> (it also works when called by Cabal, as Cabal passes it this flag
> automatically). However, we would like to have it work without needing
> to use any special flags, and without having to use it from within a
> Cabal package.
>
> The obvious solution to this problem would seem to be to put HsFFI.h in
>     /usr/lib/hsc2hs/include
> and have hsc2hs automatically add that to the include path. However,
> hsc2hs is supposed to be a compiler-independent tool, and HsFFI.h isn't
> a compiler-independent header file; for example, GHC's implementation
> defines HsInt to be a 64-bit integer type on amd64, whereas hugs's
> implementation defines it to be a 32-bit type. We therefore need a
> different HsFFI.h depending on which compiler we are using.
>
> One option would be to have hsc2hs (when installed with GHC) append
> "-I /usr/lib/ghc-6.10.1/include" to the commandline. If the user gives a
> "-I /usr/lib/hugs/include" flag then this path will be looked at first,
> and the hugs HsFFI.h will be used.
>
> Another option would be for the user to tell hsc2hs which compiler
> they're using, e.g.
>     hsc2hs --compiler=/usr/bin/ghc Foo.hsc
> (this "compiler" is distinct from the C compiler that hsc2hs will use).
> hsc2hs will then pass the appropriate -I flag, depending on what sort of
> compiler it is told to use. The hsc2hs that comes with GHC would
> probably default to using the GHC that it is installed with, but
> standalone hsc2hs would probably default to searching for /usr/bin/ghc,
> /usr/bin/hugs, etc.
>
> This last approach would also make it possible for hsc2hs to take
> "-package foo" flags, and add the include paths for the requested
> packages too.
>
> The downside is that it's pushing a lot more knowledge into hsc2hs,
> which means there is one more thing to keep in sync.
>
>
> Has anyone got any other alternatives to consider? Or opinions on which
> solution is best?
>
>
> Thanks
> Ian
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>