[Haskell] cabal and ghcconfigure.h

Robert Dockins robdockins at fastmail.fm
Tue Dec 6 09:38:51 EST 2005


On Dec 5, 2005, at 10:31 PM, Isaac Jones wrote:

> "Robert" <robdockins at 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



More information about the Haskell mailing list