Copyright | (c) 2003-2005 Isaac Jones Malcolm Wallace |
---|---|
License | BSD3 |
Maintainer | cabal-devel@haskell.org |
Portability | portable |
Safe Haskell | Safe-Inferred |
Language | Haskell2010 |
This defines a PreProcessor
abstraction which represents a pre-processor
that can transform one kind of file into another.
Synopsis
- newtype Suffix = Suffix String
- data PreProcessor = PreProcessor {
- platformIndependent :: Bool
- ppOrdering :: Verbosity -> [FilePath] -> [ModuleName] -> IO [ModuleName]
- runPreProcessor :: (FilePath, FilePath) -> (FilePath, FilePath) -> Verbosity -> IO ()
- builtinHaskellSuffixes :: [Suffix]
- builtinHaskellBootSuffixes :: [Suffix]
Documentation
A suffix (or file extension).
Mostly used to decide which preprocessor to use, e.g. files with suffix "y"
are usually processed by the "happy"
build tool.
Instances
Pretty Suffix Source # | |
Defined in Distribution.Simple.PreProcess.Types prettyVersioned :: CabalSpecVersion -> Suffix -> Doc # | |
Structured Suffix Source # | |
Defined in Distribution.Simple.PreProcess.Types | |
IsString Suffix Source # | |
Defined in Distribution.Simple.PreProcess.Types fromString :: String -> Suffix # | |
Generic Suffix Source # | |
Show Suffix Source # | |
Binary Suffix Source # | |
Eq Suffix Source # | |
Ord Suffix Source # | |
type Rep Suffix Source # | |
Defined in Distribution.Simple.PreProcess.Types |
data PreProcessor Source #
The interface to a preprocessor, which may be implemented using an external program, but need not be. The arguments are the name of the input file, the name of the output file and a verbosity level. Here is a simple example that merely prepends a comment to the given source file:
ppTestHandler :: PreProcessor ppTestHandler = PreProcessor { platformIndependent = True, runPreProcessor = mkSimplePreProcessor $ \inFile outFile verbosity -> do info verbosity (inFile++" has been preprocessed to "++outFile) stuff <- readFile inFile writeFile outFile ("-- preprocessed as a test\n\n" ++ stuff) return ExitSuccess
We split the input and output file names into a base directory and the rest of the file name. The input base dir is the path in the list of search dirs that this file was found in. The output base dir is the build dir where all the generated source files are put.
The reason for splitting it up this way is that some pre-processors don't simply generate one output .hs file from one input file but have dependencies on other generated files (notably c2hs, where building one .hs file may require reading other .chi files, and then compiling the .hs file may require reading a generated .h file). In these cases the generated files need to embed relative path names to each other (eg the generated .hs file mentions the .h file in the FFI imports). This path must be relative to the base directory where the generated files are located, it cannot be relative to the top level of the build tree because the compilers do not look for .h files relative to there, ie we do not use "-I .", instead we use "-I dist/build" (or whatever dist dir has been set by the user)
Most pre-processors do not care of course, so mkSimplePreProcessor and runSimplePreProcessor functions handle the simple case.
PreProcessor | |
|