Re: hsc2hs and HsFFI.h
On Tue, 2009-02-10 at 17:15 +, 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? I don't see nice solutions here. It's not nice to have each compiler ship their own variant/wrapper of hsc2hs (which one gets to be /usr/bin/hsch2s ?). It's also not nice for hsc2hs to have to know about each different compiler. It's worst to have ghc get taught how to compile .hsc files. My suggestion is to avoid the problem. Why does hsc2hs need to know anything about which Haskell compiler? It's because it #includes HsFFI.h in its default hsc template. Why does it need to include HsFFI.h? Well, actually it probably doesn't need to at all. The HsFFI.h is not needed by code in the hsc template itself and nor is it needed by other code generated by hsc2hs as far as I can tell. Does anyone remember why HsFFI.h was included in the default hsc template? My guess it's there as a convenience for those modules that need things from HsFFI.h. I speculate that the number of .hsc modules that actually need this header file is very low. So my suggestion is that in those few cases where it is needed, it should be specified explicitly in the .hsc file. In such cases it is the responsibility of the build system to use the right -I include dir. Cabal does this ok and others can do it too if needed. To see if this is viable we'd want to check that building a bunch of packages from hackage that use hsc2hs works with a modified template file. This test should be relatively easy to perform, though would take several hours of building. Sound plausible? Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs and HsFFI.h
I went ahead and implemented --print-hsc-options to jhc, which will spit out something like '-I/usr/share/jhc-0.5/include' suitable for passing to the hsc2hs command line. It seemed like the most straightforward route of the choices mentioned. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs and HsFFI.h
Currently, hsc2hs (as shipped with GHC) cannot be used with just hsc2hs Foo.hsc as it cannot find HsFFI.h The hsc2hs repo includes a shell script (yes, I know, no good on Windows) called hsc2hs.wrapper that already adds some default arguments. (nhc98 has a modified version of the script, adding a -I$(includedir)) Another option would be for the user to tell hsc2hs which compiler they're using, e.g. hsc2hs --compiler=/usr/bin/ghc Foo.hsc On my system, hsc2hs is already installed as hsc2hs-ghc, in addition to the plain hsc2hs, so if I want the compiler-specific tool, I can use it directly. (nhc98 should do the same thing, i.e. install hsc2hs-nhc98, but I believe for historical reasons, it simply avoids installing hsc2hs at all, to avoid conflicts with the ghc one.) Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
hsc2hs and HsFFI.h
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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs and HsFFI.h
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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs and HsFFI.h
Q: is the information that --print-libdir returns available programmatically to Haskell code? $ ghc --print-libdir C:\ghc\ghc-6.11.20090118 $ ghc -e GHC.Paths.libdir C:\\ghc\\ghc-6.11.20090118 $ ghc -e ':browse GHC.Paths' docdir :: FilePath ghc :: FilePath ghc_pkg :: FilePath libdir :: FilePath $ ghc-pkg find-module GHC.Paths c:/ghc/ghc-6.11.20090118\package.conf: ghc-paths-0.1.0.5 Claus ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
