Re: [Haskell] cabal and ghcconfigure.h
On Dec 1, 2005, at 10:18 AM, Duncan Coutts wrote:
On Wed, 2005-11-30 at 22:48 -0500, Robert Dockins wrote:
I've just run across a problem with my cabal build system -- I'm not yet sure if this is a cabal problem or a system configuration problem.
I've been developing a package on OSX using the ghc 6.4.1 and cabal from darwinports. All is fine and dandy. However, today I've sucked my darcs repo down to my machine at home (running Gentoo linux) and now my package won't build. (this time with GHC 6.4.1 from portage and cabal 1.1.3)
It halts while apparently running an Alex generated lexer through CPP, with the error:
ghcconfig.h: No such file or directory
My GHC install has this file at /usr/lib/ghc-6.4.1/include, but it clearly isn't in the include path that cabal is using.
So the question is -- is this a cabal bug of some kind, or is the gentoo setup messed up some how? How should I proceed?
Are you using cpphs?
No, both environments do not have cpphs installed.
When you use ghc to do the 'cpp'ing it adds -I/usr/lib/ghc-6.4.1/include but if Cabal is using cpphs then I suspect that it will not.
You can pass -v to Cabal to get it to show you exactly what it is invoking:
runhaskell Setup.lhs build -v
Alternatively you can specify the /usr/lib/ghc-6.4.1/include directory in the "include-dirs" field in the .cabal file, however this is not ideal of course since that path will vary between systems and ghc versions.
Yes, but this seems like exactily the kind of thing we'd like to avoid. The major difference between the two machines seems to be the version of cabal. On my mac (where compilation works), cabal version 1.0 is installed, whereas on my gentoo machine cabal 1.1.3 is installed (both with GHC 6.4.1). Neither command line has a '-I' option. Any ideas? The following output was generated on the OSX machine: --------------------------------------------------------------------------------------------- $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.4.1 $ ghc-pkg -list /opt/local/lib/ghc-6.4.1/package.conf: rts-1.0, base-1.0, haskell98-1.0, template-haskell-1.0, unix-1.0, Cabal-1.0, parsec-1.0, haskell-src-1.0, network-1.0, QuickCheck-1.0, HUnit-1.1, mtl-1.0, fgl-5.2, X11-1.1, HGL-3.1, OpenGL-2.0, GLUT-2.0, stm-1.0, readline-1.0, (lang-1.0), (concurrent-1.0), (posix-1.0), (util-1.0), (data-1.0), (text-1.0), (net-1.0), (hssource-1.0) $ runhaskell Setup.hs configure -v Warning: No license-file field. Configuring Cmm-0.1... configure: searching for ghc in path. configure: found ghc at /opt/local/bin/ghc /opt/local/bin/ghc --version >tmp19500 configure: looking for package tool: ghc-pkg near compiler in /opt/local/bin/ghc configure: found package tool in /opt/local/bin/ghc-pkg configure: Using install prefix: /usr/local configure: Using compiler: /opt/local/bin/ghc configure: Compiler flavor: GHC configure: Compiler version: 6.4.1 configure: Using package tool: /opt/local/bin/ghc-pkg configure: Using haddock: /opt/local/bin/haddock configure: Using happy: /opt/local/bin/happy configure: Using alex: /opt/local/bin/alex configure: Using hsc2hs: /opt/local/bin/hsc2hs configure: No cpphs found configure: Reading installed packages... /opt/local/bin/ghc-pkg --global list >tmp19500 $ runhaskell Setup.hs build -v Reading parameters from /Users/rdocki01/code/cmm/Cmm.buildinfo Preprocessing library Cmm-0.1... /opt/local/bin/alex -g -osrc/Language/Cmm/Parser/CmmLex.hs src/Language/Cmm/Parser/CmmLex.x /opt/local/bin/happy -agc -osrc/Language/Cmm/Parser/CmmParser.hs src/Language/Cmm/Parser/CmmParser.y Preprocessing executables for Cmm-0.1... Building Cmm-0.1... /opt/local/bin/ghc -package-name Cmm -odir dist/build/src -hidir dist/build/src --make -isrc Language.Cmm.Frontend Language.Cmm.Datatypes Language.Cmm.Parser Language.Cmm.Lint Language.Cmm.Messages Language.Cmm.Messages.EN Language.Cmm.Parser.CmmLex Language.Cmm.Parser.CmmParser Language.Cmm.Parser.PPrSyntax Language.Cmm.Parser.Syntax Language.Cmm.Parser.Tokens Language.Cmm.Parser.ParseMonad Language.Cmm.Parser.ParserUtils Language.Cmm.Parser.LexUtils Language.Cmm.Lint.SymbolTable Language.Cmm.Lint.BuildTables Language.Cmm.Lint.LintMonad Language.Cmm.Lint.Typecheck Language.Cmm.Lint.LintProc Language.Cmm.Lint.LintConstants Language.Cmm.Lint.LintTop Chasing modules from: Language.Cmm.Frontend,Language.Cmm.Datatypes,Language.Cmm.Parser,Language.Cmm.Lint,Language.Cmm.Messages,Language.Cmm.Messages.EN,Language.Cmm.Parser.CmmLex,Language.Cmm.Parser.CmmParser,Language.Cmm.Parser.PPrSyntax,Language.Cmm.Parser.Syntax,Language.Cmm.Parser.Tokens,Language.Cmm.Parser.ParseMonad,Language.Cmm.Parser.ParserUtils,Language.Cmm.Parser.LexUtils,Language.Cmm.Lint.SymbolTable,Language.Cmm.Lint.BuildTables,Language.Cmm.Lint.LintMonad,Language.Cmm.Lint.Typecheck,Language.Cmm.Lint.LintProc,Language.Cmm.Lint.LintConstants,Language.Cmm.Lint.LintTop Compiling Language.Cmm.Lint.SymbolTable ( src/Language/Cmm/Lint/SymbolTable.hs, dist/build/src/Language/Cmm/Lint/SymbolTable.o ) Compiling Language.Cmm.Datatypes ( src/Language/Cmm/Datatypes.hs, dist/build/src/Language/Cmm/Datatypes.o ) [ snip a bunch of successful compile messages ] This output was generated on the gentoo machine where compilation fails: --------------------------------------------------------------------------------------------------------------- $ ghc-pkg -list /usr/lib/ghc-6.4.1/package.conf: rts-1.0, base-1.0, haskell98-1.0, template-haskell-1.0, unix-1.0, parsec-1.0, haskell-src-1.0, network-1.0, QuickCheck-1.0, HUnit-1.1, mtl-1.0, fgl-5.2, X11-1.1, HGL-3.1, OpenGL-2.0, GLUT-2.0, stm-1.0, readline-1.0, (lang-1.0), (concurrent-1.0), (posix-1.0), (util-1.0), (data-1.0), (text-1.0), (net-1.0), (hssource-1.0), Cabal-1.1.3 $ runhaskell Setup.hs configure -v Setup.hs: Warning: No license-file field. Configuring Cmm-0.1... configure: searching for ghc in path. configure: found ghc at /usr/bin/ghc "/usr/bin/ghc" --version >tmp8374 configure: looking for package tool: ghc-pkg near compiler in /usr/bin/ghc configure: found package tool in /usr/bin/ghc-pkg configure: Using install prefix: /usr/local configure: Using compiler: /usr/bin/ghc configure: Compiler flavor: GHC configure: Compiler version: 6.4.1 configure: Using package tool: /usr/bin/ghc-pkg configure: No haddock found configure: Using happy: /usr/bin/happy configure: Using alex: /usr/bin/alex configure: Using hsc2hs: /usr/bin/hsc2hs configure: No c2hs found configure: No cpphs found configure: No greencard found configure: Reading installed packages... "/usr/bin/ghc-pkg" --global list >tmp8374 $ runhaskell Setup.hs build -v Preprocessing library Cmm-0.1... /usr/bin/alex -g -o src/Language/Cmm/Parser/CmmLex.hs src/Language/Cmm/Parser/CmmLex.x /usr/bin/happy -agc -o src/Language/Cmm/Parser/CmmParser.hs src/Language/Cmm/Parser/CmmParser.y Preprocessing executables for Cmm-0.1... Building Cmm-0.1... /usr/bin/ghc -package-name Cmm -odir dist/build -hidir dist/build -hide-all-packages --make -i -isrc Language.Cmm.Frontend Language.Cmm.Datatypes Language.Cmm.Parser Language.Cmm.Lint Language.Cmm.Messages Language.Cmm.Messages.EN Language.Cmm.Parser.CmmLex Language.Cmm.Parser.CmmParser Language.Cmm.Parser.PPrSyntax Language.Cmm.Parser.Syntax Language.Cmm.Parser.Tokens Language.Cmm.Parser.ParseMonad Language.Cmm.Parser.ParserUtils Language.Cmm.Parser.LexUtils Language.Cmm.Lint.SymbolTable Language.Cmm.Lint.BuildTables Language.Cmm.Lint.LintMonad Language.Cmm.Lint.Typecheck Language.Cmm.Lint.LintProc Language.Cmm.Lint.LintConstants Language.Cmm.Lint.LintTop Chasing modules from: Language.Cmm.Frontend,Language.Cmm.Datatypes,Language.Cmm.Parser,Language.Cmm.Lint,Language.Cmm.Messages,Language.Cmm.Messages.EN,Language.Cmm.Parser.CmmLex,Language.Cmm.Parser.CmmParser,Language.Cmm.Parser.PPrSyntax,Language.Cmm.Parser.Syntax,Language.Cmm.Parser.Tokens,Language.Cmm.Parser.ParseMonad,Language.Cmm.Parser.ParserUtils,Language.Cmm.Parser.LexUtils,Language.Cmm.Lint.SymbolTable,Language.Cmm.Lint.BuildTables,Language.Cmm.Lint.LintMonad,Language.Cmm.Lint.Typecheck,Language.Cmm.Lint.LintProc,Language.Cmm.Lint.LintConstants,Language.Cmm.Lint.LintTop src/Language/Cmm/Parser/CmmLex.hs:19: ghcconfig.h: No such file or directory The offending file has the same opening, which looks like: ------------------------------------------------------------------------------------- {-# OPTIONS -fglasgow-exts -cpp #-} {-# LINE 1 "src/Language/Cmm/Parser/CmmLex.x" #-} module Language.Cmm.Parser.CmmLex ( lexer , lexAll , lexTokens ) where import Numeric import Data.Char import Language.Cmm.Messages import Language.Cmm.Datatypes( Name(..), PrimOp(..) ) import Language.Cmm.Parser.Tokens import Language.Cmm.Parser.LexUtils import Language.Cmm.Parser.ParseMonad #if __GLASGOW_HASKELL__ >= 603 #include "ghcconfig.h" #else #include "config.h" #endif #if __GLASGOW_HASKELL__ >= 503 import Data.Array import Data.Char (ord) import Data.Array.Base (unsafeAt) -- Robert robdockins@fastmail.fm -- http://www.fastmail.fm - The professional email service
"Robert" <robdockins@fastmail.fm> writes:
On Dec 1, 2005, at 10:18 AM, Duncan Coutts wrote:
On Wed, 2005-11-30 at 22:48 -0500, Robert Dockins wrote:
I've just run across a problem with my cabal build system -- I'm not yet sure if this is a cabal problem or a system configuration problem.
Is this a public darcs repository so I can try this out on my own? (snip)
$ runhaskell Setup.hs build -v Preprocessing library Cmm-0.1... /usr/bin/alex -g -o src/Language/Cmm/Parser/CmmLex.hs src/Language/Cmm/Parser/CmmLex.x /usr/bin/happy -agc -o src/Language/Cmm/Parser/CmmParser.hs src/Language/Cmm/Parser/CmmParser.y Preprocessing executables for Cmm-0.1... Building Cmm-0.1... /usr/bin/ghc -package-name Cmm -odir dist/build -hidir dist/build -hide-all-packages --make -i -isrc Language.Cmm.Frontend
It looks like you're not listing CPP as an extension, and therefore Cabal is not doing anything whatsoever wrt cpp. It's not adding the -cpp argument to ghc, and it's not preprocessing the sources beforehand... (snip)
Chasing modules from: Language.Cmm.Frontend,Language.Cmm.Datatypes,Language.Cmm.Parser,Language.Cmm.Lint,Language.Cmm.Messages,Language.Cmm.Messages.EN,Language.Cmm.Parser.CmmLex,Language.Cmm.Parser.CmmParser,Language.Cmm.Parser.PPrSyntax,Language.Cmm.Parser.Syntax,Language.Cmm.Parser.Tokens,Language.Cmm.Parser.ParseMonad,Language.Cmm.Parser.ParserUtils,Language.Cmm.Parser.LexUtils,Language.Cmm.Lint.SymbolTable,Language.Cmm.Lint.BuildTables,Language.Cmm.Lint.LintMonad,Language.Cmm.Lint.Typecheck,Language.Cmm.Lint.LintProc,Language.Cmm.Lint.LintConstants,Language.Cmm.Lint.LintTop src/Language/Cmm/Parser/CmmLex.hs:19: ghcconfig.h: No such file or directory
There's the error...
The offending file has the same opening, which looks like: -------------------------------------------------------------------------------------
{-# OPTIONS -fglasgow-exts -cpp #-}
So you are listing extensions in the source files rather than the .cabal file, which should be OK (except that it's non-portable, of course). So cabal really shouldn't have anything to do with it. So it _should_ be all about how cabal is calling GHC... The question is, if the cpp flag is getting to ghc, why isn't ghc itself looking for the ghcconfig.h file? Looks like the difference is here: WORKING VERSION:
/opt/local/bin/ghc -package-name Cmm -odir dist/build/src -hidir dist/build/src --make -isrc Language.Cmm.Frontend Language.Cmm.Datatypes (...)
BROKEN VERSION:
/usr/bin/ghc -package-name Cmm -odir dist/build -hidir dist/build -hide-all-packages --make -i -isrc Language.Cmm.Frontend (...)
But either way, it seems to work for me on my simple test cases, so I can't reproduce it with cabal-head (1.1.4) or 1.1.3. Can you either let me see your code or create a small test case that fails? Another option is to try to construct a ghc command line which will work on both machines. If you paste the working version onto the command line on the broken machine, does it still not work? Same versions of alex? BTW, does cpphs do anything with ghcconfig.h? Should cabal be adding that include path somewhere in the cases where it uses cpphs? peace, isaac
Isaac Jones <ijones@syntaxpolice.org> writes:
BTW, does cpphs do anything with ghcconfig.h? Should cabal be adding that include path somewhere in the cases where it uses cpphs?
cpphs has no pre-defined macros, and no predefined include paths. If you want it to pretend to be ghc -cpp, you need to add arguments like -D__GLASGOW_HASKELL__=604 -I/usr/local/lib/ghc-6.4.1/includes explicitly. (More generally, you might want to record such arguments in a little wrapper script that calls cpphs.) Regards, Malcolm
On Dec 5, 2005, at 10:31 PM, Isaac Jones wrote:
"Robert" <robdockins@fastmail.fm> writes:
On Dec 1, 2005, at 10:18 AM, Duncan Coutts wrote:
On Wed, 2005-11-30 at 22:48 -0500, Robert Dockins wrote:
I've just run across a problem with my cabal build system -- I'm not yet sure if this is a cabal problem or a system configuration problem.
Is this a public darcs repository so I can try this out on my own?
I'ts semi-public. Its avaliable, but I don't consider it ready for alpha release so its not been announced. You can find it at http://www.eecs.tufts.edu/~rdocki0/cmm So I guess its announced now :)
(snip)
$ runhaskell Setup.hs build -v Preprocessing library Cmm-0.1... /usr/bin/alex -g -o src/Language/Cmm/Parser/CmmLex.hs src/Language/Cmm/Parser/CmmLex.x /usr/bin/happy -agc -o src/Language/Cmm/Parser/CmmParser.hs src/Language/Cmm/Parser/CmmParser.y Preprocessing executables for Cmm-0.1... Building Cmm-0.1... /usr/bin/ghc -package-name Cmm -odir dist/build -hidir dist/build -hide-all-packages --make -i -isrc Language.Cmm.Frontend
It looks like you're not listing CPP as an extension, and therefore Cabal is not doing anything whatsoever wrt cpp. It's not adding the -cpp argument to ghc, and it's not preprocessing the sources beforehand...
OK. The only files that request CPP are the Alex and Happy files, so I didn't think to add it. However, it seems to be doing the preprocessing, otherwise I'm not sure how it would generate an error telling me it can't find a header file. I'll try that as a first step and see what happens.
(snip)
Chasing modules from: Language.Cmm.Frontend,Language.Cmm.Datatypes,Language.Cmm.Parser,Lang uage.Cmm.Lint,Language.Cmm.Messages,Language.Cmm.Messages.EN,Language .Cmm.Parser.CmmLex,Language.Cmm.Parser.CmmParser,Language.Cmm.Parser. PPrSyntax,Language.Cmm.Parser.Syntax,Language.Cmm.Parser.Tokens,Langu age.Cmm.Parser.ParseMonad,Language.Cmm.Parser.ParserUtils,Language.Cm m.Parser.LexUtils,Language.Cmm.Lint.SymbolTable,Language.Cmm.Lint.Bui ldTables,Language.Cmm.Lint.LintMonad,Language.Cmm.Lint.Typecheck,Lang uage.Cmm.Lint.LintProc,Language.Cmm.Lint.LintConstants,Language.Cmm.L int.LintTop src/Language/Cmm/Parser/CmmLex.hs:19: ghcconfig.h: No such file or directory
There's the error...
The offending file has the same opening, which looks like: --------------------------------------------------------------------- ----------------
{-# OPTIONS -fglasgow-exts -cpp #-}
So you are listing extensions in the source files rather than the .cabal file, which should be OK (except that it's non-portable, of course).
Actually, alex is adding that. Cabal adds the -g option to the Alex call, so Alex emits GHC specific constructs.
So cabal really shouldn't have anything to do with it. So it _should_ be all about how cabal is calling GHC... The question is, if the cpp flag is getting to ghc, why isn't ghc itself looking for the ghcconfig.h file?
Right; this is what doesn't make sense to me. I'd expect GHC to know where to find its own supporting files.
Looks like the difference is here: WORKING VERSION:
/opt/local/bin/ghc -package-name Cmm -odir dist/build/src -hidir dist/build/src --make -isrc Language.Cmm.Frontend Language.Cmm.Datatypes (...)
BROKEN VERSION:
/usr/bin/ghc -package-name Cmm -odir dist/build -hidir dist/build -hide-all-packages --make -i -isrc Language.Cmm.Frontend (...)
But either way, it seems to work for me on my simple test cases, so I can't reproduce it with cabal-head (1.1.4) or 1.1.3. Can you either let me see your code or create a small test case that fails?
Another option is to try to construct a ghc command line which will work on both machines. If you paste the working version onto the command line on the broken machine, does it still not work?
If you can't reproduce from the repository I'll try to trim down a test case.
Same versions of alex?
I believe so, but I'll check when I get home. A visual inspection showed at least the beginning of the output files to be identical.
BTW, does cpphs do anything with ghcconfig.h? Should cabal be adding that include path somewhere in the cases where it uses cpphs?
peace,
isaac
I'ts semi-public. Its avaliable, but I don't consider it ready for alpha release so its not been announced. You can find it at http://www.eecs.tufts.edu/~rdocki0/cmm
So I guess its announced now :)
Grrrr.... URL typo, sorry. Try: http://www.eecs.tufts.edu/~rdocki01/cmm
[snip]
So you are listing extensions in the source files rather than the .cabal file, which should be OK (except that it's non-portable, of course). So cabal really shouldn't have anything to do with it. So it _should_ be all about how cabal is calling GHC... The question is, if the cpp flag is getting to ghc, why isn't ghc itself looking for the ghcconfig.h file? Looks like the difference is here:
WORKING VERSION:
/opt/local/bin/ghc -package-name Cmm -odir dist/build/src -hidir dist/build/src --make -isrc Language.Cmm.Frontend Language.Cmm.Datatypes
(...)
BROKEN VERSION:
/usr/bin/ghc -package-name Cmm -odir dist/build -hidir dist/build -hide-all-packages --make -i -isrc Language.Cmm.Frontend
(...)
Removing the -hide-all-packages flag from the command line causes the package to compile. Apparently if package "base" is not in scope, then GHC won't find ghcconfig.h in the preprocess phase. Is there ever a reason for the base package not to be in scope? If cabal is going to add the -hide-all-packages flag, then perhaps it should also add -package base? Adding a Build-Depends clause to my cabal file with all my dependencies fixes the problem.
Robert Dockins <robdockins@fastmail.fm> writes:
[snip]
So you are listing extensions in the source files rather than the .cabal file, which should be OK (except that it's non-portable, of course). So cabal really shouldn't have anything to do with it. So it _should_ be all about how cabal is calling GHC... The question is, if the cpp flag is getting to ghc, why isn't ghc itself looking for the ghcconfig.h file? Looks like the difference is here:
WORKING VERSION:
/opt/local/bin/ghc -package-name Cmm -odir dist/build/src -hidir dist/build/src --make -isrc Language.Cmm.Frontend Language.Cmm.Datatypes
(...)
BROKEN VERSION:
/usr/bin/ghc -package-name Cmm -odir dist/build -hidir dist/build -hide-all-packages --make -i -isrc Language.Cmm.Frontend
(...)
Removing the -hide-all-packages flag from the command line causes the package to compile. Apparently if package "base" is not in scope, then GHC won't find ghcconfig.h in the preprocess phase.
Ahh, I did not know that.
Is there ever a reason for the base package not to be in scope? If cabal is going to add the -hide-all-packages flag, then perhaps it should also add -package base?
Build dependencies have to be exact starting with GHC 6.4.1. We added the hide-all-package flag so that users will get exact build dependencies in their .cabal files instead of just relying on the packages they have on their systems. People may not want to depend on base, for instance if they just want to be haskell98, so that's why cabal doesn't automatically make a build dependency on base. Sorry that this was tricky to debug.
Adding a Build-Depends clause to my cabal file with all my dependencies fixes the problem.
Excellent! peace, isaac
participants (4)
-
Isaac Jones -
Malcolm Wallace -
Robert -
Robert Dockins