When parsing haskell source files that contain #define and #if, parseFileContentsWithMode gets confused and throws an error about the hash. I tried to include MagicHash and CPP in the extension list (extns, see below) but that didn't work. I can't really change the source files because there are a lot of them.
getModule extns filePath program = fromParseResult $ parseFileContentsWithMode mode program
where
bangPatternsExt = map parseExtension extns
mode = ParseMode filePath Haskell2010 bangPatternsExt False False
The parser failed at:
#if __GLASGOW_HASKELL__ >= 612
instance Lift ModName where
lift = lift . modString
Haskell-src-exts doesn't support CPP natively (there is no issue in the GitHub issue tracker for that, but an old one on trac at http://trac.haskell.org/haskell-src-exts/ticket/27).
You can look at solution or workarounds for haskell-src-exts parsing modules with CPP failing for workarounds (using cpphs).
There is also a package called hse-cpp (https://hackage.haskell.org/package/hse-cpp) that looks like it can run cpphs for you, but I haven't used it, and it doesn't seem to get updated a lot.
Related
I'm working on a project that's chosen CMake as its build tool. The project is made up of several executables and since a few months back a few of them are written in Haskell. We strongly wish all executables to show the same version number when called as foo --version. Ideally that version should be recorded in one place, and ideally that place should be the top-level CMakeLists.txt (this is where the source for all the other executables get it, via the use of CMake's configure_file function).
Is there some nice way of achieving this?
Some extra information that might be useful:
The source for each executable lives in its own dir, with its own Cabal file.
We use stack to build, and there is a single stack.yaml file that points to all directories with Haskell code.
I thought I'd document the solution I've landed on.
the source changes
I added the CPP language extension and use a macro (VERSION) to chose between a version provided as a CPP macro and the version provided by Cabal:
{-# LANGUAGE CPP #-}
module Main where
import Data.Version
import Text.ParserCombinators.ReadP
.... -- other imports
#ifdef VERSION
#define xstr(s) str(s)
#define str(s) #s
version = fst $ last $ readP_to_S parseVersion xstr(VERSION)
#else
import Paths_<Cabal project name> (version)
#endif
The need for the double-expansion (xstr and str) is explained in the answer to another question.
building
The above code will unfortunately not build with a simple stack build command. This apparently has to do with the default CPP that ghc uses (/usr/bin/gcc) and the flags it passes to it (as I understand it the culprit is -traditional). The solution is to tell ghc to use GNU CPP:
stack build --ghc-options "-pgmP=/usr/bin/cpp -DVERSION=1.2.3"
or as I put it in my CMakeLists.txt (I use ExternalProject to integrate stack into our CMake-based build):
ExternalProject_Add(haskell-bits
...
BUILD_COMMAND cd <SOURCE_DIR>
&& ${HaskellStack_EXE} --local-bin-path <BINARY_DIR> --install-ghc
install --ghc-options "-pgmP=/usr/bin/cpp -DVERSION=${<CMake proj name>_VERSION}"
...
)
I try to visualize an existing Haskell code base with SourceGraph.
SourceGraph mycabal.cabal
But all I get are error messages like this:
Could not parse source file ./src/mysource.hs
SourceGraph: Could not find data file templates/default.html
Any hints what to do or where to look for documentation?
The only documentation I have found so far is this one: http://code.haskell.org/~ivanm/Sample_SourceGraph/SourceGraph/SourceGraph.html which unfortunately only consists of catchy images but with no hints how to produce them.
Regarding your immediate question, it seems like the best documentation here is the source: http://code.haskell.org/SourceGraph/
I tried it on a repository of my own, and ran into the parsing issue, too. This is haskell-src-exts failing to parse a module. The following patch shows the actual error:
--- Parsing.hs 2013-02-14 12:59:34.000000000 +0100
+++ ../SourceGraph-0.7.0.5-fixed/Parsing.hs 2014-04-08 20:49:54.000000000 +0200
## -64,7 +64,7 ##
parseFile :: FileContents -> Either FilePath Module
parseFile (p,f) = case (parseFileContentsWithMode mode f) of
(ParseOk hs) -> Right hs
- _ -> Left p
+ x -> Left $ p ++ ": " ++ show x
where
mode = defaultParseMode { parseFilename = p
, fixities = Nothing
It turns out that most of my failing modules failed because "MultiParamTypeClasses is not enabled". This is apparently haskell-src-exts being rightfully strict, while ghc is happy without the MultiParamTypeClasses extension: https://github.com/haskell-suite/haskell-src-exts/issues/29
So as a quick fix, try adding
{-# LANGUAGE MultiParamTypeClasses #-}
at the top of your failing modules.
Just ran into a similar issue, so I thought I'd document here what I did. I put my changes in a patch file.
https://gist.github.com/ivanperez-keera/b398ce71a22e8a4849f3
cabal sandbox init
cabal unpack SourceGraph
wget https://gist.githubusercontent.com/ivanperez-keera/b398ce71a22e8a4849f3/raw/bf26ffc45564934c0f175e7619ded8a299a9b7d5/verbose-sourcegraph.patch
cd SourceGraph-0.7.0.6/
patch -i ../verbose-sourcegraph.patch
cd ..
cabal install SourceGraph-0.7.0.6/
Most of the "errors" in my files where due to bang patterns and multi param type classes. There must be a better solution to make SourceGraph's parse mode default to the same as GHC.
In my current project I have a file Tokens.x that needs to be compiled to Tokens.hs by Alex. In my .cabal file I have listed Tokens in the other-modules section and cabal build happily creates the file.
However it does so without the -g option that instructs Alex to create a GHC optimized version of the file. This option represents a 10x speed up in scanning when used with GHC and is also an order of magnitude faster to compile.
How do I tell cabal to included the -g option when compiling using GHC?
AFAIK, with Cabal you can currently only specify program options in the configuration file or via the command line, but not in a .cabal file.
There's an open issue about this: https://github.com/haskell/cabal/issues/1223
However, looking at the sources for Cabal, I find that your particular problem seems to be solved by default. In Distribution.Simple.PreProcess, there's:
ppAlex :: BuildInfo -> LocalBuildInfo -> PreProcessor
ppAlex _ lbi = pp { platformIndependent = True }
where pp = standardPP lbi alexProgram (hcFlags hc)
hc = compilerFlavor (compiler lbi)
hcFlags GHC = ["-g"]
hcFlags _ = []
This means that if Cabal is used with GHC, then -g is automatically passed to Alex when it's being used as a preprocessor.
What's the best way to iterate over all the modules (files) in a given package? Concretely, suppose I have
an executable called "runThis"
a cabal package P with files F1.hs, F2.hs, ..., Fn.hs
Whats the easiest way to execute:
runThis F1.hs
runThis F2.hs
...
runThis Fn.hs
?
I thought I might try --with-compiler but that fails with
cabal: The program ghc version >=6.4 is required but the version of runThis
(The other option looks like tweaking the Setup.lhs -- but ideally I'd like to hijack the build process and use "runThis" instead of, say, ghc)
Thanks!
From Duncan Coutts' email:
Question: How to add the preprocessor? I have tried
main =
defaultMainWithHooks
simpleUserHooks{hookedPreProcessors=[("foo",transformation)]}
transformation :: BuildInfo -> LocalBuildInfo -> PreProcessor
That looks right. Here's how to complete it (example taken from the
Cabal haddock docs for the PreProcess module):
transformation _ _ =
PreProcessor {
platformIndependent = True,
runPreProcessor =
mkSimplePreProcessor $ \inFile outFile verbosity -> do
fail $ "transformation: " ++ inFile ++ " " ++ outFile
}
and it works fine:
runghc Setup.hs build
Preprocessing library foo-1.0...
Setup.hs: transformation: Abc.foo dist/build/Abc.hs
But under which circumstances will this function be called? Up to now
I have not succeeded in making cabal call this function.
It calls it when it goes and looks for the module Abc (ie Abc.hs
or .lhs), and since if does not find it, it'll check through the list of
preprocessors and go looking for the corresponding files, ie Abc.foo.
I decided to add some flags to control the way that C source file is compiled (i.e. something like use-clang, use-intel etc.).
C-Sources: c_lib/tiger.c
Include-Dirs: c_lib
Install-Includes: tiger.h
if flag(debug)
GHC-Options: -debug -Wall -fno-warn-orphans
CPP-Options: -DDEBUG
CC-Options: -DDEBUG -g
else
GHC-Options: -Wall -fno-warn-orphans
Question is: which options in descritpion file need to be modified to change C compiler? I did found only CC-Options.
There is no straightforward way, but it is possible.
Assuming that you are using Distribution.Simple, you basically need to add a user hook to the build stage.
All of the following changes need to appear in Setup.hs:
Change main to use a build hook, something like:
main :: IO ()
main = defaultMainWithHooks simpleUserHooks { buildHook = myBuildHook }
Next you need a build hook. It will likely look something like the following:
myBuildHook pkg_descr local_bld_info user_hooks bld_flags =
do
let lib = fromJust (library pkg_descr)
lib_bi = libBuildInfo lib
custom_bi = customFieldsBI lib_bi
cpp_name = fromJust (lookup "x-cc-name" custom_bi)
c_srcs = cSources lib_bi
cc_opts = ccOptions lib_bi
inc_dirs = includeDirs lib_bi
lib_dirs = extraLibDirs lib_bi
bld_dir = buildDir local_bld_info
-- Compile C/C++ sources
putStrLn "invoking my compile phase"
objs <- mapM (compileCxx cpp_name cc_opts inc_dirs bld_dir) c_srcs
-- Remove C/C++ source code from the hooked build (don't change libs)
let lib_bi' = lib_bi { cSources = [] }
lib' = lib { libBuildInfo = lib_bi' }
pkg_descr' = pkg_descr { library = Just lib' }
-- The following line invokes the standard build behaviour
putStrLn "Invoke default build hook"
bh <- buildHook simpleUserHooks pkg_descr' local_bld_info user_hooks bld_flags
return bh
The code above probably needs unpacking a bit. The let clauses are basically about unpacking the required data fields from the structures passed to the build hook. Notice that you can create custom stanzas in your foo.cabal. I have provided the code to support a stanza something like:
x-cc-name: icc
As a means to specify your compiler. Having extracted all of the source files, you map over them using a function to compile a single file (NB: this is sub-optimal in some cases, e.g. those compilers which can efficiently compile multiple source files to produce a single object output and benefit from large scale optimizations, but we'll leave that aside for now).
Last of all, as we've now compiled the C/C++ code, remove it from the build structures before you pass everything on to the default build hook.
Sorry that this is more of a 'HOWTO' than a canned answer, but it should help you to get going.
I should mention that the code is untested. I have adapted it from some work I have been doing on the wxHaskell build system, so I know the idea works fine. The Cabal API is actually pretty well documented - it suffers mainly from being somewhat unstable around some of these areas.
There really doesn't seem to be any way to specify this in a .cabal file; the only thing we seem to have at the moment that would be even remotely useful here is --with-<prog>=path.
I suggest you try filing a ticket against Cabal on the trac.
4.10.1. Replacing the program for one or more phases
-pgmc cmd
Use cmd as the C compiler.
This works for ghc --make, but I'm not sure how to get Cabal to apply this to the C file compilation.