X-Git-Url: http://git.megacz.com/?p=ghc-hetmet.git;a=blobdiff_plain;f=docs%2Fusers_guide%2Fpackages.xml;h=dbc0ea9b59be1cfa0ea14dc64d929dedb9e42f22;hp=f209d57b5af0a8ab718e6448931d1c448e79a95d;hb=530ced58cd18b165d03b6f62ff513c83c4fa4718;hpb=f35cbb251108d6371fe9287418366a3c4e82e8dd diff --git a/docs/users_guide/packages.xml b/docs/users_guide/packages.xml index f209d57..dbc0ea9 100644 --- a/docs/users_guide/packages.xml +++ b/docs/users_guide/packages.xml @@ -5,12 +5,15 @@ Packages packages - A package is a library of Haskell modules known to the compiler. GHC - comes with several packages: see the accompanying - library documentation. + A package is a library of Haskell modules known to the + compiler. GHC comes with several packages: see the accompanying + library + documentation. More packages to install can be obtained + from HackageDB. Using a package couldn't be simpler: if you're using - or GHCi, then most of the installed packages will be + or GHCi, then most of the installed packages will be automatically available to your program without any further options. The exceptions to this rule are covered below in . @@ -30,33 +33,76 @@ Packages packages using - To see which packages are installed, use the - ghc-pkg command: + GHC only knows about packages that are + installed. To see which packages are installed, use + the ghc-pkg list command: $ ghc-pkg list -/usr/lib/ghc-6.4/package.conf: - base-1.0, haskell98-1.0, template-haskell-1.0, mtl-1.0, unix-1.0, - Cabal-1.0, haskell-src-1.0, parsec-1.0, network-1.0, - QuickCheck-1.0, HUnit-1.1, fgl-1.0, X11-1.1, HGL-3.1, OpenGL-2.0, - GLUT-2.0, stm-1.0, readline-1.0, (lang-1.0), (concurrent-1.0), - (posix-1.0), (util-1.0), (data-1.0), (text-1.0), (net-1.0), - (hssource-1.0), rts-1.0 - - - Packages are either exposed or hidden. Only - modules from exposed packages may be imported by your Haskell code; if - you try to import a module from a hidden package, GHC will emit an error - message. - - Each package has an exposed flag, which says whether it is exposed by - default or not. Packages hidden by default are listed in - parentheses (eg. (lang-1.0)) in the output from - ghc-pkg list. To expose a package which is hidden by - default, use the - flag (see below). - - To see which modules are exposed by a package: +/usr/lib/ghc-6.12.1/package.conf.d: + Cabal-1.7.4 + array-0.2.0.1 + base-3.0.3.0 + base-4.2.0.0 + bin-package-db-0.0.0.0 + binary-0.5.0.1 + bytestring-0.9.1.4 + containers-0.2.0.1 + directory-1.0.0.2 + (dph-base-0.4.0) + (dph-par-0.4.0) + (dph-prim-interface-0.4.0) + (dph-prim-par-0.4.0) + (dph-prim-seq-0.4.0) + (dph-seq-0.4.0) + extensible-exceptions-0.1.1.0 + ffi-1.0 + filepath-1.1.0.1 + (ghc-6.12.1) + ghc-prim-0.1.0.0 + haskeline-0.6.2 + haskell98-1.0.1.0 + hpc-0.5.0.2 + integer-gmp-0.1.0.0 + mtl-1.1.0.2 + old-locale-1.0.0.1 + old-time-1.0.0.1 + pretty-1.0.1.0 + process-1.0.1.1 + random-1.0.0.1 + rts-1.0 + syb-0.1.0.0 + template-haskell-2.4.0.0 + terminfo-0.3.1 + time-1.1.4 + unix-2.3.1.0 + utf8-string-0.3.4 + + + An installed package is either exposed + or hidden by default. Packages hidden by + default are listed in parentheses + (eg. (lang-1.0)), or possibly in blue if your + terminal supports colour, in the output of ghc-pkg + list. Command-line flags, described below, allow you + to expose a hidden package or hide an exposed one. Only modules + from exposed packages may be imported by your Haskell code; if + you try to import a module from a hidden package, GHC will emit + an error message. + + + + Note: if you're using Cabal, then the exposed or hidden status + of a package is irrelevant: the available packages are instead + determined by the dependencies listed in + your .cabal specification. The + exposed/hidden status of packages is only relevant when + using ghc or ghci + directly. + + + To see which modules are provided by a package use the + ghc-pkg command (see ): $ ghc-pkg field network exposed-modules @@ -67,12 +113,6 @@ exposed-modules: Network.BSD, Network - In general, packages containing hierarchical modules are usually - exposed by default. However, it is possible for two packages to contain - the same module: in this case, only one of the packages should be - exposed. It is an error to import a module that belongs to more than one - exposed package. - The GHC command line options that control packages are: @@ -82,24 +122,36 @@ exposed-modules: Network.BSD, - This option causes package P to be - exposed. The package P can be specified - in full with its version number - (e.g. network-1.0) or the version number can be - omitted if there is only one version of the package - installed. - - If there are multiple versions of P - installed, then all other versions will become hidden. + This option causes the installed + package P to be exposed. The + package P can be specified in + full with its version number + (e.g. network-1.0) or the version + number can be omitted if there is only one version of the + package installed. If there are multiple versions + of P installed, then all other + versions will become hidden. The - option also causes package P to be - linked into the resulting executable. In - mode and GHCi, the compiler - normally determines which packages are required by the current - Haskell modules, and links only those. In batch mode however, the - dependency information isn't available, and explicit - options must be given when linking. + option also causes package P to + be linked into the resulting executable or shared + object. Whether a packages' library is linked statically + or dynamically is controlled by the flag + pair /. + + In mode + and mode (see + ), the compiler normally + determines which packages are required by the current + Haskell modules, and links only those. In batch mode + however, the dependency information isn't available, and + explicit + options must be given when linking. The one other time you might need to use + to force linking a package is + when the package does not contain any Haskell modules (it + might contain a C library only, for example). In that + case, GHC will never discover a dependency on it, so it + has to be mentioned explicitly. For example, to link a program consisting of objects Foo.o and Main.o, where @@ -111,18 +163,7 @@ exposed-modules: Network.BSD, The same flag is necessary even if we compiled the modules from source, because GHC still reckons it's in batch mode: -$ ghc -o myprog Foo.hs Main.hs -package network - - In --make and --interactive - modes (), however, GHC figures out the - packages required for linking without further assistance. - - The one other time you might need to use - to force linking a package is when the - package does not contain any Haskell modules (it might contain a C - library only, for example). In that case, GHC - will never discover a dependency on it, so it has to be mentioned - explicitly. +$ ghc -o myprog Foo.hs Main.hs -package network @@ -180,11 +221,44 @@ exposed-modules: Network.BSD, useful. + + + foo + + + + Tells GHC the the module being compiled forms part of + package foo. + If this flag is omitted (a very common case) then the + default package main is assumed. + Note: the argument to + should be the full package identifier for the package, + that is it should include the version number. For example: + -package mypkg-1.2. + + + + The main package + + Every complete Haskell program must define main in + module Main + in package main. (Omitting the flag compiles + code for package main.) Failure to do so leads to a somewhat obscure + link-time error of the form: + +/usr/bin/ld: Undefined symbols: +_ZCMain_main_closure +___stginit_ZCMain + + + + + - Consequences of packages + Consequences of packages for the Haskell language It is possible that by using packages you might end up with a program that contains two modules with the same name: perhaps @@ -214,21 +288,34 @@ exposed-modules: Network.BSD, Package Databases - A package database is a file, normally called - package.conf which contains descriptions of installed - packages. GHC usually knows about two package databases: + + A package database is where the details about installed packages + are stored. It is a directory, usually + called package.conf.d, that contains a file + for each package, together with a binary cache of the package + data in the file package.cache. Normally + you won't need to look at or modify the contents of a package + database directly; all management of package databases can be + done through the ghc-pkg tool (see + ). + + + + GHC knows about two package databases in particular: + The global package database, which comes with your GHC - installation. + installation, + e.g. /usr/lib/ghc-6.12.1/package.conf.d. A package database private to each user. On Unix systems this will be - $HOME/.ghc/arch-os-version/package.conf, and on + $HOME/.ghc/arch-os-version/package.conf.d, and on Windows it will be something like - C:\Documents And Settings\user\ghc. + C:\Documents And Settings\user\ghc\package.conf.d. The ghc-pkg tool knows where this file should be located, and will create it if it doesn't exist (see ). @@ -239,11 +326,11 @@ exposed-modules: Network.BSD, see GHC's package table by running GHC with the flag. - Package databases may overlap: for example, packages in the user - database will override those of the same name in the global - database. + Package databases may overlap: for example, packages in the + user database will override (shadow) those + of the same name and version in the global database. - You can control the loading of package databses using the following + You can control the loading of package databases using the following GHC options: @@ -272,13 +359,6 @@ exposed-modules: Network.BSD, - To create a new package database, just create - a new file and put the string - [] in it. Packages can be - added to the file using the - ghc-pkg tool, described in . - The <literal>GHC_PACKAGE_PATH</literal> environment variable Environment variableGHC_PACKAGE_PATH @@ -309,124 +389,130 @@ $ export GHC_PACKAGE_PATH=$HOME/.my-ghc-packages.conf: - - Building a package from Haskell source - packages - building - - We don't recommend building packages the hard way. Instead, use the - Cabal infrastructure - if possible. If your package is particularly complicated or requires a - lot of configuration, then you might have to fall back to the low-level - mechanisms, so a few hints for those brave souls follow. - - - - You need to build an "installed package info" file for - passing to ghc-pkg when installing your - package. The contents of this file are described in . - - - - The Haskell code in a package may be built into one or - more archive libraries - (e.g. libHSfoo.a), or a single DLL on - Windows (e.g. HSfoo.dll). The - restriction to a single DLL on Windows is because the - package system is used to tell the compiler when it should - make an inter-DLL call rather than an intra-DLL call - (inter-DLL calls require an extra - indirection). Building packages as DLLs doesn't - work at the moment; see - for the gory details. - - - Building a static library is done by using the - ar tool, like so: - -ar cqs libHSfoo.a A.o B.o C.o ... - - where A.o, - B.o and so on are the compiled Haskell - modules, and libHSfoo.a is the library - you wish to create. The syntax may differ slightly on your - system, so check the documentation if you run into - difficulties. - - Versions of the Haskell libraries for use with GHCi - may also be included: GHCi cannot load .a - files directly, instead it will look for an object file - called HSfoo.o and load that. On some - systems, the ghc-pkg tool can - automatically build the GHCi version of each library, see - . To build these - libraries by hand from the .a archive, it - is possible to use GNU ld as - follows: - -ld -r ––whole-archive -o HSfoo.o libHSfoo.a - - (replace - ––--whole-archive with - –all_load on MacOS X) - - GHC does not maintain detailed cross-package - dependency information. It does remember which modules in - other packages the current module depends on, but not which - things within those imported things. - - - - To compile a module which is to be part of a new package, - use the -package-name option: + + Dependencies and broken packages + + Each installed package has a unique identifier, which + distinguishes it from all other installed packages on the + system. To see the identifiers associated with each installed + package, use ghc-pkg list -v: + + +$ ghc-pkg list -v +using cache: /usr/lib/ghc-6.12.1/package.conf.d/package.cache +/usr/lib/ghc-6.12.1/package.conf.d + Cabal-1.7.4 (Cabal-1.7.4-48f5247e06853af93593883240e11238) + array-0.2.0.1 (array-0.2.0.1-9cbf76a576b6ee9c1f880cf171a0928d) + base-3.0.3.0 (base-3.0.3.0-6cbb157b9ae852096266e113b8fac4a2) + base-4.2.0.0 (base-4.2.0.0-247bb20cde37c3ef4093ee124e04bc1c) + ... + - - - - -package-name - option - - This option is added to the command line when - compiling a module that is destined to be part of package - foo. If this flag is omitted then the - default package main is assumed. + + The string in parentheses after the package name is the unique + identifier: it normally begins with the package name and + version, and ends in a hash string derived from the compiled + package. Dependencies between packages are expressed in terms + of these unique identifiers, rather than just packages and + versions. For example, take a look at the dependencies of + the haskell98 package: + + + +$ ghc-pkg field haskell98 depends +depends: array-0.2.0.1-9cbf76a576b6ee9c1f880cf171a0928d + base-4.2.0.0-247bb20cde37c3ef4093ee124e04bc1c + directory-1.0.0.2-f51711bc872c35ce4a453aa19c799008 + old-locale-1.0.0.1-d17c9777c8ee53a0d459734e27f2b8e9 + old-time-1.0.0.1-1c0d8ea38056e5087ef1e75cb0d139d1 + process-1.0.1.1-d8fc6d3baf44678a29b9d59ca0ad5780 + random-1.0.0.1-423d08c90f004795fd10e60384ce6561 + - Note: the argument to - should be the full package identifier for the package, - that is it should include the version number. For example: - -package mypkg-1.2. - - - + + The purpose of the unique package identifier is to detect + problems caused by re-installing a package without also + recompiling the packages that depend on it. Recompiling + dependencies is necessary, because the newly compiled package + may have a differnt ABI (Application Binary Interface) than the + previous version, even if both packages were built from the same + source code using the same compiler. With unique package + identifiers, a recompiled package will have a different unique + identifer from the previous version, so packages that depended + on the previous version are now orphaned - one of their + dependencies is not satisfied. Packages that are broken in this + way are shown in the ghc-pkg list output + either in red (if possible) or otherwise surrounded by + braces. In the following example, we have recompiled and + reinstalled the filepath package, and this + has caused various dependencies + including Cabal to break: + + +$ ghc-pkg list +WARNING: there are broken packages. Run 'ghc-pkg check' for more details. +/usr/lib/ghc-6.12.1/package.conf.d: + {Cabal-1.7.4} + array-0.2.0.1 + base-3.0.3.0 + ... etc ... + - Failure to use the -package-name option - when compiling a package will probably result in disaster, but - you will only discover later when you attempt to import modules - from the package. At this point GHC will complain that the - package name it was expecting the module to come from is not the - same as the package name stored in the .hi - file. + + Additionally, ghc-pkg list reminds you that + there are broken packages and suggests ghc-pkg + check, which displays more information about the + nature of the failure: + + + +$ ghc-pkg check +There are problems in package ghc-6.12.1: + dependency "filepath-1.1.0.1-87511764eb0af2bce4db05e702750e63" doesn't exist +There are problems in package haskeline-0.6.2: + dependency "filepath-1.1.0.1-87511764eb0af2bce4db05e702750e63" doesn't exist +There are problems in package Cabal-1.7.4: + dependency "filepath-1.1.0.1-87511764eb0af2bce4db05e702750e63" doesn't exist +There are problems in package process-1.0.1.1: + dependency "filepath-1.1.0.1-87511764eb0af2bce4db05e702750e63" doesn't exist +There are problems in package directory-1.0.0.2: + dependency "filepath-1.1.0.1-87511764eb0af2bce4db05e702750e63" doesn't exist + +The following packages are broken, either because they have a problem +listed above, or because they depend on a broken package. +ghc-6.12.1 +haskeline-0.6.2 +Cabal-1.7.4 +process-1.0.1.1 +directory-1.0.0.2 +bin-package-db-0.0.0.0 +hpc-0.5.0.2 +haskell98-1.0.1.0 + - It is worth noting that on Windows, when each package - is built as a DLL, since a reference to a DLL costs an extra - indirection, intra-package references are cheaper than - inter-package references. Of course, this applies to the - main package as well. - + + To fix the problem, you need to recompile the broken packages + against the new dependencies. The easiest way to do this is to + use cabal-install, or download the packages + from HackageDB + and build and install them as normal. + + Be careful not to recompile any packages that GHC itself + depends on, as this may render the ghc + package itself broken, and ghc cannot be + simply recompiled. The only way to recover from this would be + to re-install GHC. + Package management (the <literal>ghc-pkg</literal> command) packages management - The ghc-pkg tool allows packages to be - added or removed from a package database. By default, - the system-wide package database is modified, but alternatively - the user's local package database or another specified - file can be used. - - To see what package databases are in use, say + The ghc-pkg tool is for querying and + modifying package databases. To see what package databases are + in use, use ghc-pkg list. The stack of databases that ghc-pkg knows about can be modified using the GHC_PACKAGE_PATH environment variable (see options are given, the rightmost one is used as the database to act upon. + Commands that query the package database (list, latest, + describe, field, dot) operate on the list of databases specified by + the flags , , and + . If none of these flags are + given, the default is + . + If the environment variable GHC_PACKAGE_PATH is set, and its value does not end in a separator (: on Unix, ; on Windows), then the last database is @@ -462,6 +555,15 @@ $ export GHC_PACKAGE_PATH=$HOME/.my-ghc-packages.conf: + ghc-pkg init path + + Creates a new, empty, package database + at path, which must not already + exist. + + + + ghc-pkg register file Reads a package specification from @@ -501,6 +603,15 @@ $ export GHC_PACKAGE_PATH=$HOME/.my-ghc-packages.conf: + ghc-pkg check + + Check consistency of dependencies in the package + database, and report packages that have missing + dependencies. + + + + ghc-pkg hide P Sets the exposed flag for package @@ -534,6 +645,26 @@ $ export GHC_PACKAGE_PATH=$HOME/.my-ghc-packages.conf: + ghc-pkg find-module M [] + + This option lists registered packages exposing module + M. Examples: + +$ ghc-pkg find-module Var +c:/fptools/validate/ghc/driver/package.conf.inplace: + (ghc-6.9.20080428) + +$ ghc-pkg find-module Data.Sequence +c:/fptools/validate/ghc/driver/package.conf.inplace: + containers-0.1 + + Otherwise, it behaves like ghc-pkg list, + including options. + + + + + ghc-pkg latest P Prints the latest available version of package @@ -549,18 +680,103 @@ $ export GHC_PACKAGE_PATH=$HOME/.my-ghc-packages.conf: InstalledPackageInfo, the same as the input file format for ghc-pkg register. See for details. + + If the pattern matches multiple packages, the + description for each package is emitted, separated by the + string --- on a line by itself. - ghc-pkg field P field + ghc-pkg field P field[,field]* Show just a single field of the installed package description - for P. + for P. Multiple fields can be selected by separating + them with commas + + + ghc-pkg dot + + + Generate a graph of the package dependencies in a form + suitable for input for the graphviz tools. For example, + to generate a PDF of the dependency graph: + +ghc-pkg dot | tred | dot -Tpdf >pkgs.pdf + + + + + + ghc-pkg dump + + Emit the full description of every package, in the + form of an InstalledPackageInfo. + Multiple package descriptions are separated by the + string --- on a line by itself. + + This is almost the same as ghc-pkg describe '*', except that ghc-pkg dump + is intended for use by tools that parse the results, so + for example where ghc-pkg describe '*' + will emit an error if it can't find any packages that + match the pattern, ghc-pkg dump will + simply emit nothing. + + + + + ghc-pkg recache + + + Re-creates the binary cache + file package.cache for the selected + database. This may be necessary if the cache has somehow + become out-of-sync with the contents of the database + (ghc-pkg will warn you if this might be + the case). + + + The other time when ghc-pkg recache is + useful is for registering packages manually: it is + possible to register a package by simply putting the + appropriate file in the package database directory and + invoking ghc-pkg recache to update the + cache. This method of registering packages may be more + convenient for automated packaging systems. + + + + + Substring matching is supported for M in + find-module and for P in + list, describe, and + field, where a '*' indicates open + substring ends (prefix*, *suffix, + *infix*). Examples (output omitted): + + + -- list all regex-related packages + ghc-pkg list '*regex*' --ignore-case + -- list all string-related packages + ghc-pkg list '*string*' --ignore-case + -- list OpenGL-related packages + ghc-pkg list '*gl*' --ignore-case + -- list packages exporting modules in the Data hierarchy + ghc-pkg find-module 'Data.*' + -- list packages exporting Monad modules + ghc-pkg find-module '*Monad*' + -- list names and maintainers for all packages + ghc-pkg field '*' name,maintainer + -- list location of haddock htmls for all packages + ghc-pkg field '*' haddock-html + -- dump the whole database + ghc-pkg describe '*' + + Additionally, the following flags are accepted by ghc-pkg: @@ -603,7 +819,7 @@ $ export GHC_PACKAGE_PATH=$HOME/.my-ghc-packages.conf: databases. Additionally, file will also be the database modified by a register, unregister, expose or - hide command, unless it is overriden by a later + hide command, unless it is overridden by a later , or option. @@ -668,6 +884,23 @@ $ export GHC_PACKAGE_PATH=$HOME/.my-ghc-packages.conf: + + nghc-pkg + option + + + =nghc-pkg option + + + + Control verbosity. Verbosity levels range from 0-2, where + the default is 1, and alone selects + level 2. + + + + + @@ -682,14 +915,109 @@ $ export GHC_PACKAGE_PATH=$HOME/.my-ghc-packages.conf: - When modifying the package database - file, a copy of the original file is - saved in file.old, - so in an emergency you can always restore the old settings by - copying the old file back again. - + + Building a package from Haskell source + packages + building + + We don't recommend building packages the hard way. Instead, use the + Cabal infrastructure + if possible. If your package is particularly complicated or requires a + lot of configuration, then you might have to fall back to the low-level + mechanisms, so a few hints for those brave souls follow. + + You need to build an "installed package info" file for + passing to ghc-pkg when installing your + package. The contents of this file are described in + . + + The Haskell code in a package may be built into one or more + archive libraries (e.g. libHSfoo.a), or a + single shared object + (e.g. libHSfoo.dll/.so/.dylib). The + restriction to a single shared object is because the package + system is used to tell the compiler when it should make an + inter-shared-object call rather than an intra-shared-object-call + call (inter-shared-object calls require an extra + indirection). + + Building a static library is done by using the + ar tool, like so: + +ar cqs libHSfoo-1.0.a A.o B.o C.o ... + + where A.o, + B.o and so on are the compiled Haskell + modules, and libHSfoo.a is the library you + wish to create. The syntax may differ slightly on your system, + so check the documentation if you run into difficulties. + + + Versions of the Haskell libraries for use with GHCi may also + abe included: GHCi cannot load .a files + directly, instead it will look for an object file + called HSfoo.o and load that. On some + systems, the ghc-pkg tool can automatically + build the GHCi version of each library, see + . To build these libraries + by hand from the .a archive, it is possible + to use GNU ld as follows: + +ld -r ––whole-archive -o HSfoo.o libHSfoo.a + + (replace + ––whole-archive with + –all_load on MacOS X) + + + When building the package as shared library, GHC can be used to + perform the link step. This hides some of the details + out the underlying linker and provides a common + interface to all shared object variants that are supported + by GHC (DLLs, ELF DSOs, and Mac OS dylibs). The shared + object must be named in specific way for two reasons: (1) + the name must contain the GHC compiler version, so that two + library variants don't collide that are compiled by + different versions of GHC and that therefore are most likely + incompatible with respect to calling conventions, (2) it + must be different from the static name otherwise we would + not be able to control the linker as precisely as necessary + to make + the / flags + work, see . + +ghc -shared libHSfoo-1.0-ghcGHCVersion.so A.o B.o C.o + Using GHC's version number in the shared object name + allows different library versions compiled by different GHC + versions to be installed in standard system locations, + e.g. under *nix /usr/lib. To obtain the version number of + GHC invoke ghc --numeric-version and use + its output in place + of GHCVersion. See also + on how object files must + be prepared for shared object linking. + + + + To compile a module which is to be part of a new package, + use the -package-name option (). + Failure to use the -package-name option + when compiling a package will probably result in disaster, but + you will only discover later when you attempt to import modules + from the package. At this point GHC will complain that the + package name it was expecting the module to come from is not the + same as the package name stored in the .hi + file. + + It is worth noting with shared objects, when each package + is built as a single shared object file, since a reference to a shared object costs an extra + indirection, intra-package references are cheaper than + inter-package references. Of course, this applies to the + main package as well. + + <literal>InstalledPackageInfo</literal>: a package specification @@ -709,46 +1037,51 @@ $ export GHC_PACKAGE_PATH=$HOME/.my-ghc-packages.conf:</screen> <screen> $ ghc-pkg describe unix name: unix -version: 1.0 +version: 2.3.1.0 +id: unix-2.3.1.0-de7803f1a8cd88d2161b29b083c94240 license: BSD3 copyright: maintainer: libraries@haskell.org stability: homepage: package-url: -description: -category: +description: This package gives you access to the set of operating system + services standardised by POSIX 1003.1b (or the IEEE Portable + Operating System Interface for Computing Environments - + IEEE Std. 1003.1). + . + The package is not supported under Windows (except under Cygwin). +category: System author: exposed: True -exposed-modules: System.Posix, - System.Posix.DynamicLinker.Module, - System.Posix.DynamicLinker.Prim, - System.Posix.Directory, - System.Posix.DynamicLinker, - System.Posix.Env, - System.Posix.Error, - System.Posix.Files, - System.Posix.IO, - System.Posix.Process, - System.Posix.Resource, - System.Posix.Temp, - System.Posix.Terminal, - System.Posix.Time, - System.Posix.Unistd, - System.Posix.User, - System.Posix.Signals.Exts -import-dirs: /usr/lib/ghc-6.4/libraries/unix -library-dirs: /usr/lib/ghc-6.4/libraries/unix -hs-libraries: HSunix -extra-libraries: HSunix_cbits, dl -include-dirs: /usr/lib/ghc-6.4/libraries/unix/include -includes: HsUnix.h -depends: base-1.0 +exposed-modules: System.Posix System.Posix.DynamicLinker.Module + System.Posix.DynamicLinker.Prim System.Posix.Directory + System.Posix.DynamicLinker System.Posix.Env System.Posix.Error + System.Posix.Files System.Posix.IO System.Posix.Process + System.Posix.Process.Internals System.Posix.Resource + System.Posix.Temp System.Posix.Terminal System.Posix.Time + System.Posix.Unistd System.Posix.User System.Posix.Signals + System.Posix.Signals.Exts System.Posix.Semaphore + System.Posix.SharedMem +hidden-modules: +import-dirs: /usr/lib/ghc-6.12.1/unix-2.3.1.0 +library-dirs: /usr/lib/ghc-6.12.1/unix-2.3.1.0 +hs-libraries: HSunix-2.3.1.0 +extra-libraries: rt util dl +extra-ghci-libraries: +include-dirs: /usr/lib/ghc-6.12.1/unix-2.3.1.0/include +includes: HsUnix.h execvpe.h +depends: base-4.2.0.0-247bb20cde37c3ef4093ee124e04bc1c +hugs-options: +cc-options: +ld-options: +framework-dirs: +frameworks: +haddock-interfaces: /usr/share/doc/ghc/html/libraries/unix/unix.haddock +haddock-html: /usr/share/doc/ghc/html/libraries/unix </screen> - <para>The full <ulink url="../Cabal/index.html">Cabal documentation</ulink> - is still in preparation (at time of writing), so in the meantime - here is a brief description of the syntax of this file:</para> + <para>Here is a brief description of the syntax of this file:</para> <para>A package description consists of a number of field/value pairs. A field starts with the field name in the left-hand column followed by a @@ -800,6 +1133,17 @@ depends: base-1.0 <varlistentry> <term> + <literal>id</literal> + <indexterm><primary><literal>id</literal></primary><secondary>package specification</secondary></indexterm> + </term> + <listitem> + <para>The package's unique identifier. It is up to you to + choose a suitable one.</para> + </listitem> + </varlistentry> + + <varlistentry> + <term> <literal>version</literal> <indexterm><primary><literal>version</literal></primary><secondary>package specification</secondary></indexterm> </term> @@ -1100,10 +1444,8 @@ depends: base-1.0 <indexterm><primary><literal>depends</literal></primary><secondary>package specification</secondary></indexterm> </term> <listitem> - <para>(package name list) Packages on which this package depends. This field contains - packages with explicit versions are required, except that when - submitting a package to <literal>ghc-pkg register</literal>, the - versions will be filled in if they are unambiguous.</para> + <para>(package id list) Packages on which this package + depends.</para> </listitem> </varlistentry>