GitLab

We used to miss a lot of conflicts during counting in `logBackjump`.
Counting initial conflicts here drastically reduces search time in some
cases.
Not sure whether counting the current conflicts (`cs`) may be even
better than counting the initial conflicts (`initial`).

David Luposchainsky authored Oct 08, 2016 and Herbert Valerio Riedel committed Oct 08, 2016

This definition was both in the module, and in a CPP-conditionally imported
other module. This patch removes this redundancy.

In the normal Cabal build this was not an issue, since it uses a newer version
of QuickCheck. The Stack-based build however still uses an old one, which lead
to both the import as well as the local definition from being in the code. The
testsuite would then fail with a duplicate definition error.

Fixes haskell/cabal#3950

Add ModuleName.fromComponents

Fix Stack build

The hackage-security dependency in stack.yaml (0.5.2.1) is incompatible
with what cabal-install requires (>=0.5.2.2). Bumping the version to that
lower bound resolves the issue.

Pass -this-component-id to GHC when necessary.

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

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

You never want those packages; you want the indefinite one
which you'll improve into a definite one.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

The primary consequence is that we can't assume that we
have a ComponentId when we have a UnitId in hand.  Most
of the time, this just means we have to pass around
ComponentId explicitly.  No problem.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Also fix a wibble in GHC's output in this case.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Previously GHC inferred it off of -this-unit-id but we've
modified things so that GHC makes no assumptions about the
format of instantiated unit ids. In that case, pass it in
explicitly!
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Lower library compatibility version to 1.25, since 1.25 is dev series…

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

Only reregister inplace package if we built it.

Backpack

Make the initial '~/.cabal/config' comment more obvious.

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>

The DefUnitId invariant says that the UnitId in a DefUnitId
must in fact be a definite package (either with no holes, or
fully instantiated.)  This is in constrast to a UnitId,
which can also identify an indefinite unit identifier.
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>

Here are the main changes:

Distribution/Client/InstallPlan.hs
    New utility function 'fromSolverInstallPlanWithProgress'
    which is a monadic version of 'fromSolverInstallPlan'.
    This is because, with Backpack, the conversion from
    'SolverInstallPlan' to 'InstallPlan' can fail/log.

Distribution/Client/ProjectPlanning/Types.hs
    OK. A bunch of new information we need to track.

    New fields in 'ElaboratedConfiguredPackage':
        elabInstantiatedWith :: ModuleSubst (for --instantiated-with)
        elabLinkedInstantiatedWith :: IndefModuleSubst (intermediate)
        elabModuleShape :: ModuleShape (for mix-in linking)

    Here is how all the dependency functions relate to
    one another:

        elabOrderDependencies :: [UnitId]
            Used for nodeNeighbors, this just specifies what needs
            to be built before we build this module.  These refer
            either to fully instantiated unit ids (hashed unit id)
            or uninstantiated unit ids (effectively component id)
            but never a partially instantiated unit id, since we
            never have an install item in our plan for a partially
            instantiated package.

            These dependencies are factored into two parts:
                elabOrderLibDependencies
                elabOrderExeDependencies
            which soley are used to determine if we need to enable
            executables/libraries of a package we are building
            (this isn't new)

        elabLibDependencies :: [ComponentId]
            These are the things we pass to Setup using the --dependency
            flag; so they are JUST ComponentId, not a full on UnitId.
            The mix-in linking process in Setup will reconstruct the
            necessary UnitId.

        elabExeDependencies :: [ComponentId]
            These are the things that we must add to the PATH to run.
            At the moment, this coincides with elabOrderExeDependencies.

    For components, there is also:

        compLinkedLibDependencies :: [IndefUnitId],
            The partially instantiated unit ids that GHC would be
            invoked with, if we were invoking it directly.
            This is used when we subsequently instantiate components.

        compNonSetupDependencies :: [UnitId]
            Non-setup, ORDER dependencies; i.e., everything that has
            to be built before us that is not a setup script.

Distribution/Client/ProjectPlanning.hs
    The workhorse.

    Essentially, we redo all of the steps from
    Distribution.Backpack.Configure, but in the context of planning an
    entire install plan.  The conversion from SolverInstallPlan
    to InstallPlan is responsible for mix-in linking
    (inside elaborateSolverToComponents); afterwards,
    instantiateInstallPlan is responsible for filling in
    the missing, instantiated packages which we need to compile.
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>

Add a clarification in packageTemplateEnv

Improve the pre-processing message so we can see which unit is being
built, not just the source component name.

Debug output while building to print out the installed package info
when we register information.

Remove a done TODO about making sure the installed package registration
files do not clash with each other, by including the full UnitId. This
did not need any code changes here since dislaying the UnitId does the
right thing.

1) Bugfix so that we get library source files from the correct
   directories (it was wrong previously; it only ever looked
   in the library directory)
2) Search for hsig/lhsig files when looking for source files