GitLab

A new module with utilities for managing the store. This includes a new
approach for store updates that allows for concurrent updates to the
store from different processes.

This relies on the new file locking code. We log a message if we wait
for a store file lock. This should be a rare occurrence in practice,
but would help debugging if some other zombie process was holding the
file lock.

This code is backported from base from ghc-8.2.

It will be used as part of the concurrent store updates. It may also be
used in future to work around the lack of file locking in ghc-pkg prior
to version 8.2.

This makes the necessary changes to 4dc0f30fc36914ee2f01bde016bee98b8e0bb0bb
to handle component configuring correctly.  It probably is a good step
towards pkg:lib style dependencies.

The big ideas:

* There's a new AnnotatedId type, which is any identifier (like
  ComponentId), but also with a PackageId and ComponentName.
  It's a bit like ConfiguredId, but ConfiguredId is specialized
  for ComponentId.  There's a conversion function
  annotatedIdToConfiguredId.

* We adopt a totally new strategy for handling MungedPackageId in
  InstalledPackageInfo.  Rather than store the munged package
  identifier in IPI, we NEVER store it, instead computing it
  from the package name and library name (which are stored.)
  There is now code to PARSE a munged package name into these
  two components, so that when we read 'name' we get the
  correct info.  The resulting code is splendidly clear.

* Some places where we took a ComponentName (notably
  computeCompatPackageName) we now take 'Maybe UnqualComponentName'.
  This is more accurate, because compatibility package names are
  only computed for libraries, not other components.  Some code
  in Distribution.Backpack.ReadyComponent is partial now,
  but the invariants should hold up.

* A number of places where MungedId was applied, I undid them.
  Most notable are macro generation (that should be PACKAGES,
  not components) and mkLegacyUnitId (since REALLY old style
  unit identifiers, we won't support internal libraries anyway.)

* Many functions in PackageIndex are monomorphized to
  InstalledPackageInfo.  Fortunately cabal-install's usage
  still works.

* Distribution/Client/SolverPlanIndex.hs, not used by anyone,
  got the axe.

* Dependency solving has a hack to solve the problem of how to
  interpret installed internal libraries in the package database.
  The basic idea is that, although in most cases where we used
  a MungedId, we say it explicitly, in the SOLVER, we munge
  *installed package names* only, and keep the type PackageName.
  It's a hack, but the alternative is to write a lot more code.
  Note that is MORALLY PN is indeed a PackageName, since we really
  are solving for honest to goodness packages, not components!
  See Note [Index conversion with internal libraries] for more
  details.

* ConfiguredId now records the ComponentName.  This is quite important,
  because we need to use it to figure out how we are going to phrase
  --dependency.  In fact, it is a miracle that this worked at all
  (and it only worked because of a very skeevy update to the PackageId
  in the creation of ConfiguredComponent).  Irritatingly, this must
  be a Maybe ComponentName, because a ConfiguredId MIGHT refer to
  a setup component. Very distressing.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Fixes bug where cabal exec with foreign libraries didn't
actually work on Windows (because it was selecting
the wrong library directory).
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Needed to stop logging dir change to stdout
to make test output deterministic.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Formatting into reasonably readable error messages for all of the
TargetProblem cases for each command. There's quite a bit of overlap
possible here which we put into common code in a new module.

Also take the opportunity to move some other error formatting into the
shared module.

This covers some of the positive cases of target selector resolution
and pretty much all of the negative cases for each command.

We already had tests covering valid syntax. This adds tests for invalid
syntax and ambigious cases. Also cases for empty projects, or when there
is no cwd package.

So this covers most cases that are expected to work. Still need to do
cases that are invalid syntax, unrecognised, or ambigious.

Also added a note about a bit of an inconsistency in how we treat source
file targets.

So far they just build the exe bench and don't do the next steps,
but they do at least select the right components to build.

Also bring the existing test command into sync with the others.

kristenk authored Feb 19, 2017 and Mikhail Glushenkov committed Feb 21, 2017

I added a function, 'debugAssert', that wraps 'assert' and only calls it when
the build flag 'debug-assertions' is enabled.  The flag defaults to false. I
only replaced one call to 'assert' so far (in Distribution.Solver.Modular.Linking)
in order to resolve #4258.

kristenk authored Feb 18, 2017 and Mikhail Glushenkov committed Feb 20, 2017

This fixes #4299. The change gives the dependency solver the flexibility to link
dependencies when the user has only set a manual flag on one of them.
Previously, the solver would force the constrained dependency to have the
flag value from the constraint and force the unconstrained dependency to have
the default flag value. In cases where the single instance restriction required
the dependencies to be linked, the solver couldn't find a solution.

Qualified constraints can still be used to force different dependencies on a
package to use different flag values. For example,
"--constraint 'pkg +flag' --constraint 'pkg2:setup.pkg -flag'" turns the flag on
for the top-level dependency and off for the setup dependency.

I also stored flag default values in the search tree to simplify the code.

* This is only enabled with the lib flag.
* We tell users not to use the library in the package description.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This reverts commit bacdf19b.

'hackage-security' has been updated. I tested that build works now.

hackage-security hasn't been updated with new bounds, so this
unbreaks the build.

This reverts commit eec15a35.

echo-0.1.3 introduces a dependency on the minimalistic mintty library, so we
need to add that to ./bootstrap.sh as well.