GitLab

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>

This reverts commit 4774fb6558974a721176f1fb48d8ce7d43119251.

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>

This reverts commit 332d809c, reversing
changes made to 0c72bc88.

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

Use a more common type of conflict in the solver basic memory usage test.

The test previously caused the solver to backtrack because of a missing package.
Missing packages are handled as a special case in the solver, so the test didn't
exercise as much code as it could have.  This commit causes the solver to
backtrack with a version conflict, which is a more common type of failure.
Other tests continue to test the missing package case.

Don't put VQuiet in VFlags; that's reserved for user-toggles.

Since VQuiet is set programmatically, it's inappropriate
for it to be propagated to the command line.  But unfortunately,
if it was set, we were accidentally using the fancy flag format.
This patch moves VQuiet to its own field in Verbosity so we
don't get confused.

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

Filter out internal deps when forming package ElaboratedConfiguredPackage.

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

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

Prior to this patch, we were unconditionally sticking all dependencies
in a "whole package' ElaboratedConfiguredPackage, which resulted in
cycles when there were internal dependencies on the library in question,
and broken deps with convenience libraries.  Happily, the fix is simple,
although I did have to add ConfiguredId to the "extra" dependency fields
to make it easier to tell if a dependency was external or internal.

I added an extra test to make sure that we give a good error message
if a package requires per-component builds (apparently, internal
libraries require per-component builds!)

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

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

ProjectPlanning refactor

* toConfiguredComponents and friends are now monadic.  This means
  we can report a user-friendly error when we fail to find a
  dependency in the dependency map.  I had to rejigger a bit
  of the logic in ProjectPlanning since we were knot-tying through
  this function, but it all worked out.  This means
  that unbuildable_external_lib_deps is no more.

* cc_internal_build_tools is no more; instead it's cc_exe_deps,
  which tracks ALL dependencies.  It also comes with a PackageId
  so we can build ConfiguredId cabal-install side.  This change
  propagates all the way to 'ReadyComponent'

* ProjectPlanning: Instead of recomputing dependencies from scratch,
  we instead use the ElaboratedConfiguredPackages we just finished
  making to build the ComponentDeps.

* ProjectPlanning now constructs a skeletal setupComponent.  This
  is used to setup the above with correct setup dependencies.
  In principle this component might also be used for building, but
  lots of functionality isn't written in yet.

* filterExeMapDep is no more; it's all handled by Cabal now.

* The ConfiguredComponentMap now handles both libraries and
  executables in one data structure.  This is nice.

* compSetupDependencies is no more, because elaborated components
  never have custom setup.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

There's still more refactoring to do, but here is a good
first step.

* New 'foldPlanPackage' for taking care of that annoying
  thing where you really wanted an OR-pattern on Configured/Installed

* Big Note [SolverId to ConfiguredId]

* elaborate(Lib|Exe)SolverId(') has been pared down to just
  elaborateLibSolverId and elaborateExeSolverId; call sites
  are responsible for projecting out the components they're actually
  interested in.  That gives us a new 'planPackageCacheFile' and
  'planPackageExePath' helper functions (which maybe should be
  lifted out.)

* external_lib_dep_sids/etc bindings have been moved so they're
  closer together; easier to see.

* Pile of new helper functions to help shorten code.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Rework build target handling

Distinguish between true package names, and munged package names

A few things I forgot relating to build tool dependencies + slight test organization

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

There should be little-to-no functional changes with this commit

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>

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>

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>

Windows behavior for argument translation always quotes, which
is not so great for deterministic output.  And it wasn't really
necessary either, so just don't do it at all.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

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