Hoogle Search
Within LTS Haskell 24.38 (ghc-9.10.3)
Note that Stackage only displays results for the latest LTS and Nightly snapshot. Learn more.
module Distribution.Simple.
PackageDescription This defines parsers for the .cabal format
module Distribution.Simple.
PackageIndex An index of packages whose primary key is UnitId. Public libraries are additionally indexed by PackageName and Version. Technically, these are an index of *units* (so we should eventually rename it to UnitIndex); but in the absence of internal libraries or Backpack each unit is equivalent to a package. While PackageIndex is parametric over what it actually records, it is in fact only ever instantiated with a single element: The InstalledPackageIndex (defined here) contains a graph of InstalledPackageInfos representing the packages in a package database stack. It is used in a variety of ways:
- The primary use to let Cabal access the same installed package database which is used by GHC during compilation. For example, this data structure is used by 'ghc-pkg' and Cabal to do consistency checks on the database (are the references closed).
- Given a set of dependencies, we can compute the transitive closure of dependencies. This is to check if the versions of packages are consistent, and also needed by multiple tools (Haddock must be explicitly told about the every transitive package to do cross-package linking; preprocessors must know about the include paths of all transitive dependencies.)
-
Cabal Distribution.Simple.PackageIndex The collection of information about packages from one or more PackageDBs. These packages generally should have an instance of PackageInstalled Packages are uniquely identified in by their UnitId, they can also be efficiently looked up by package name or by name and version.
module Distribution.Simple.
PreProcess This module defines PPSuffixHandler, which is a combination of a file extension and a function for configuring a PreProcessor. It also defines a bunch of known built-in preprocessors like cpp, cpphs, c2hs, hsc2hs, happy, alex etc and lists them in knownSuffixHandlers. On top of this it provides a function for actually preprocessing some sources given a bunch of known suffix handlers. This module is not as good as it could be, it could really do with a rewrite to address some of the problems we have with pre-processors.
-
Cabal Distribution.Simple.PreProcess A preprocessor for turning non-Haskell files with the given Suffix (i.e. file extension) into plain Haskell source files.
-
Cabal Distribution.Simple.PreProcess 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 ExitSuccessWe 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. -
Cabal Distribution.Simple.PreProcess No documentation available.
-
Cabal Distribution.Simple.PreProcess.Types 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 ExitSuccessWe 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. -
Cabal Distribution.Simple.PreProcess.Types No documentation available.
module Distribution.Simple.
Program This provides an abstraction which deals with configuring and running programs. A Program is a static notion of a known program. A ConfiguredProgram is a Program that has been found on the current machine and is ready to be run (possibly with some user-supplied default args). Configuring a program involves finding its location and if necessary finding its version. There is also a ProgramDb type which holds configured and not-yet configured programs. It is the parameter to lots of actions elsewhere in Cabal that need to look up and run programs. If we had a Cabal monad, the ProgramDb would probably be a reader or state component of it. The module also defines all the known built-in Programs and the defaultProgramDb which contains them all. One nice thing about using it is that any program that is registered with Cabal will get some "configure" and ".cabal" helpers like --with-foo-args --foo-path= and extra-foo-args. There's also good default behavior for trying to find "foo" in PATH, being able to override its location, etc. There's also a hook for adding programs in a Setup.lhs script. See hookedPrograms in UserHooks. This gives a hook user the ability to get the above flags and such so that they don't have to write all the PATH logic inside Setup.lhs.