Hackage :: [Package]

haskell-packages: Haskell suite library for package management and integration with Cabal

[ distribution, library, mit ] [ Propose Tags ] [ Report a vulnerability ]
Versions [RSS] 0.1, 0.2, 0.2.1, 0.2.2, 0.2.3, 0.2.3.1, 0.2.3.2, 0.2.3.3, 0.2.3.4, 0.2.4, 0.2.4.1, 0.2.4.2, 0.2.4.3, 0.2.4.4, 0.3, 0.4, 0.5, 0.6, 0.6.1, 0.6.2
Change log CHANGELOG.md
Dependencies base (>=4.5 && <5), binary (>=0.8), bytestring (>=0.9), Cabal (>=2.0 && <2.1), containers, deepseq, directory, filepath, haskell-src-exts (>=1.18), hse-cpp (>=0.2), mtl (>=2.1), optparse-applicative (>=0.11), tagged, transformers (>=0.3), transformers-compat (>=0.3) [details]
Tested with ghc ==8.2.1
License MIT
Copyright (c) Roman Cheplyaka 2012, David Himmelstrup 2016-2018
Author Roman Cheplyaka
Maintainer David Himmelstrup <lemmih@gmail.com>
Category Distribution
Home page http://documentup.com/haskell-suite/haskell-packages
Bug tracker https://github.com/haskell-suite/haskell-packages/issues
Source repo head: git clone git://github.com/haskell-suite/haskell-packages.git
Uploaded by DavidHimmelstrup at 2018-03-25T08:06:27Z
Distributions
Reverse Dependencies 4 direct, 22 indirect [details]
Downloads 22796 total (81 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs available [build log]
Last success reported on 2018-03-25 [all 1 reports]

Readme for haskell-packages-0.6.1

[back to package description]

There are two cases when you may need haskell-packages: if you are writing a Haskell compiler (or any tool that processes Haskell source code, such as a static analyzer), or if you want to integrate with an existing Haskell compiler that uses haskell-packages.

Writing a compiler

If you are writing a compiler, you typically want to integrate it with Cabal, to be able to build ordinary Haskell packages.

If you go the hard way, this involves:

  1. Parsing command line parameters. Sounds easy — just take a list of files to compile. In reality you also need to handle package ids and package dbs, CPP options (-DFOO=1), language extension flags (-XRankNTypes) etc.

    To integrate with Cabal, you also need to tell it the list of installed packages, supported languages and extensions etc.

  2. Actual integration with Cabal means understanding how Cabal works and hard-coding support for your compiler. And then getting it accepted and waiting for the next Cabal release.

    You may pretend that you are GHC or other compiler that is already supported by Cabal. It might work, but often it won't, for various reasons. Also, GHC's command line protocol is quite complex.

  3. Package management. You need to implement a package db mechanism, which would let you to keep track of installed packages. Then you'd have to implement a ghc-pkg-like tool to manage those databases, for both Cabal and your users.

Or, you can simply use this library!

It already has command line options parsing, Cabal support, and package management. All you need to do is to provide the function to do actual compilation and tell a couple of other things about your compiler. See the Distribution.HaskellSuite.Compiler module for details.

Using other compilers

Some compilers produce artifacts that you may want to use. A good example is the hs-gen-iface compiler from haskell-names which generates an interface for each module — the set of all named entities (functions, types, classes) that are exported by that module. This information can be then used either by other compilers, or by tools like IDEs.

Assuming the compiler uses haskell-packages and exports its database type, it's very easy to use its artifacts. See Distribution.HaskellSuite.Packages for package resolution and Distribution.HaskellSuite.Modules for module resolution.

Usage

First, make sure that you have cabal-install from git:

git clone git@github.com:haskell/cabal.git
cd cabal
(cd Cabal && cabal install)
(cd cabal-install && cabal install)

To compile a Haskell package using a haskell-packages tool:

cabal install --haskell-suite -w $TOOL

where $TOOL may be either a full path to the compiler, or just an executable name if it's in $PATH.

Maintainers

David Himmelstrup is the primary maintainer.

Roman Cheplyaka is the original author.

Adam Bergmark is the backup maintainer. Please get in touch with him if the primary maintainer cannot be reached.