Call this after parseDynFlags. It reads the package database files, and sets up various internal tables of package information, according to the package-related flags on the command-line (-package, -hide-package etc.)

Returns a list of packages to link in if we're doing dynamic linking. This list contains the packages that the user explicitly mentioned with -package flags.

initPackages can be called again subsequently after updating the packageFlags field of the DynFlags, and it will update the pkgState in DynFlags and return a list of packages to link in.

Get a list of entries from the package database. NB: be careful with this function, although all packages in this map are "visible", this does not imply that the exposed-modules of the package are available (they may have been thinned or renamed).

Find the package we know about with the given key (e.g. foo_HASH), if any

Search for packages with a given package ID (e.g. "foo-0.1")

Looks up the package with the given id in the package state, panicing if it is not found

Takes a ModuleName, and if the module is in any package returns list of modules which take that name.

The result of performing a lookup

Package state is all stored in DynFlags, including the details of all packages, which packages are exposed, and which modules they provide.

The package state is computed by initPackages, and kept in DynFlags. It is influenced by various package flags:

• -package pkg and -package-id pkg cause pkg to become exposed. If -hide-all-packages was not specified, these commands also cause all other packages with the same name to become hidden.
• -hide-package pkg causes pkg to become hidden.
• (there are a few more flags, check below for their semantics)

The package state has the following properties.

• Let exposedPackages be the set of packages thus exposed. Let depExposedPackages be the transitive closure from exposedPackages of their dependencies.
• When searching for a module from an preload import declaration, only the exposed modules in exposedPackages are valid.
• When searching for a module from an implicit import, all modules from depExposedPackages are valid.
• When linking in a compilation manager mode, we link in packages the program depends on (the compiler knows this list by the time it gets to the link step). Also, we link in all packages which were mentioned with preload -package flags on the command-line, or are a transitive dependency of same, or are "base"/"rts". The reason for this is that we might need packages which don't contain any Haskell modules, and therefore won't be discovered by the normal mechanism of dependency tracking.

Given a module name, there may be multiple ways it came into scope, possibly simultaneously. This data type tracks all the possible ways it could have come into scope. Warning: don't use the record functions, they're partial!

Find all the include directories in these and the preload packages

Find all the library paths in these and the preload packages

Find all the link options in these and the preload packages, returning (package hs lib options, extra library options, other flags)

Find all the C-compiler options in these and the preload packages

Find all the package framework paths in these and the preload packages

Find all the package frameworks in these and the preload packages

Find all the PackageConfig in both the preload packages from DynFlags and corresponding to the list of PackageConfigs

Show (very verbose) package info

Show simplified package info.

The idea is to only print package id, and any information that might be different from the package databases (exposure, trust)

Show the mapping of modules to where they come from.

Will the Name come from a dynamically linked library?