We need to be able to specify program options and locations on a
per-pakage basis. Of course we can still specify them for all local
packages.

Note that these options are not actually used yet, which is why this
patch can be so small. Using them is next.

Move the FlagAssignment from the project-wide all-packages config to the
per-package config.

Initially it had been easier to do it globally since it gets used as a
solver setting rather than as the other per-package config items, but
obviously it is supposed to be per-package.

So the flags field in the config top-level now applies to all local
packages. And it can also be specified in package-specific sections.

We don't yet check that any of the flags specified actually make sense
for either the local packages or for the specific packages.

It's a Map PackageName PackageConfig (or LegacyPackageConfig) so the
correct monoid instance is to merge the PackageConfig values.

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

Currently, dependency solving immediately produces an 'InstallPlan'
which is then consumed by cabal install, or elaborated into
an 'ElaboratedInstallPlan' for cabal new-build.  However, this
translation is awkward, because the dependency solver knows nothing
about 'UnitId's, yet an 'InstallPlan' must indexed by 'UnitId's.
So there's a bit of faffing around to generate a "fake" unit id
to satisfy the interface, and then eventually correct it to the
right one.

So this patch starts moving us in a better direction, by introducing
a 'SolverInstallPlan', 'SolverPackage' and 'SolverId', intended
to be generated by the solver.  Then 'configureInstallPlan' or
'elaborateInstallPlan' elaborate this representation into the
representation needed by the destination.

The next step will be to generate the 'UnitId' during
'configureInstallPlan', and then we can get rid of the fake map
(so only Solver data types generate a fake identity, which
is only temporary until we generate 'UnitId's.)

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

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

This commit removes the 'ExTest' constructor from 'ExampleDependency'.
Test dependencies are now represented using the same
'ExampleDependency' constructors as library dependencies.  The only
difference between dependencies of different components is that they
are placed under different keys in 'D.C.ComponentDeps.ComponentDeps'.

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

Convenience libraries are package-private libraries
that can be used as part of executables, libraries, etc
without being exposed to the external world.  Private
libraries are signified using the

    library foo

stanza.  Within a Cabal package, the name convenience library
shadows the conventional meaning of package name in
build-depends, so that references to "foo" do not indicate
foo in Hackage, but the convenience library defined in the
same package. (So, don't shadow Hackage packages!)

This commit implements convenience libraries such that they
ARE installed the package database (this prevents us from
having to special case dynamically linked executables);
in GHC 7.10 and later they are installed under the same
package name as the package that contained them, but have
a distinct "component ID" (one pay off of making the distinction
between component IDs and installed package IDs.)

There is a "default" library which is identified by the fact
that its library name coincides with the package name.  There
are some new convenience functions to permit referencing this.

There are a few latent bugs in this commit which are fixed
in later commits in this patchset.  (Those bugfixes required
a bit of refactoring, so it's clearer if they're not
with this patch.)

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

Duncan Coutts authored 8 years ago and Mikhail Glushenkov committed 8 years ago

And extend the project config print/parse tests to cover quoted strings.

(cherry picked from commit 72b93d91)

Duncan Coutts authored 8 years ago and Mikhail Glushenkov committed 8 years ago

File globs can now be absolute, e.g. starting with / or c:\
Also allow homedir relative, ie ~/

Globs can also have a trailing slash, in which case they only match
directories, not files.

Previously whether globs could match dirs was not totally consistent.
The matchFileGlob would match dirs, but the file monitor globs would
not. The file monitor globs can now match dirs (or with a trailing
slash, only match dirs). File monitors now also detect changes in the
file type, ie switching from file to dir or the other way around.

The file monitor are now pretty consistent between single file monitors
and globs monitors. They now have equivalent capabilities and share
code. For a single file or for a glob we can now control what we
monitor if the path is a file or a dir. In both cases we can monitor
mere existence, non-existence or modification time. For files we can
additionally monitor content hash.

File monitors now also detect changes in the file type, ie switching
from file to dir or the other way around.

New tests cover all these new file monitor cases. There are also new
tests for glob syntax, covering printing/parsing round trips.

(cherry picked from commit f6c1e71c)

Duncan Coutts authored 9 years ago and Mikhail Glushenkov committed 9 years ago

Two kinds of round-trip test:
 * type conversion ProjectConfig -> LegcyProjectConfig and back
 * ProjectConfig -> print -> parse
The latter goes out to the config file format and back.

These tests uncovered a number of issues in our general config code.

(cherry picked from commit e36c0e7e)

A package path now consists of a namespace and a qualifier. The namespace is
either DefaultNamespace or Independent _i_, for some _i_; this is used for
independent top-level goals. Then the qualifier is either Unqualified
(default), Setup _pn_ for the setup dependencies of package _pn_, or Base _pn_,
for a dependency on base by package _pn_ (used only when we detect the presence
of a base shim). Qualifiers are not tested anymore.

This avoids non-termination in the solver. The unit tests now pass.

In #3170 we introduced a cycle check to the solver. This check is necessary to
reject cycling solutions (which would previously have resulted in an internal
error when we verify the install plan). However, this by itself is not
sufficient. If we have a cycle through setup dependencies, the solver loops
because it starts building an infinite tree. This is explained in detail in

In this commit we just add some unit tests that provide a minimal example that
exposes the bug.

The alias is a shorthand for 'SourcePackage UnresolvedPkgLoc' which is
used all over the place.

This is a step towards breaking the dependency from the modular
solver on cabal-install.

When solving, we now discard plans that would involve packages with a
pkgconfig-depends constraint which is not satisfiable with the current
set of installed packages (as listed by pkg-config --list-all).

This fixes https://github.com/haskell/cabal/issues/3016.

It is possible (in principle, although it should be basically impossible
in practice) that "pkg-config --modversion pkg1 pkg2... pkgN" fails to
execute for various reasons, in particular because N is too large, so
the command line becomes too long for the operating system limits.

If this happens, revert to the previous behavior of accepting any
install plan, regardless of any pkgconfig-depends constraints.

If we take the snapshot after the action has completed then we have a
problem. The problem is that files might have changed while the action
was running but /after/ the action read them. If we take the snapshot
after the action completes then we will miss these changes.

The solution is to record a timestamp before beginning execution of the
action and then we make the conservative assumption that any file that
has changed since then has already changed, ie the file monitor state
for these files will be such that checkFileMonitorChanged will report
that they have changed.

Makes use of this in the Rebuild monad so everything using this will get
the feature for free. Also adds a test.

Changed the representation of files that have already changed by the
time we take the snapshot. We had two extra constructor, but now instead
we represent it with the normal constructors but with a Maybe ModTime.
The reason is that it's easier to extend to the globbing case.

Two changes:

  * 'getModTime' now uses 'modificationTimeHiRes' instead of 'modificationTime'
    on Unix when the former is available.

  * 'ModTime' is now represented as a 64-bit unsigned integer in Windows UTC
    format (that is, 100 ns resolution and day zero is 1601-01-01) on all
    platforms. Previously we used POSIX seconds, which was wrong (low
    resolution). Sandbox timestamp files in old format are now up-converted on
    the fly.

Fixes #3132.

See https://github.com/haskell/cabal/commit/a6a7ac59b01ebdc2fdf5a410adb5ae097ce92714#commitcomment-15937386.

Tomas Vestelind authored 9 years ago and Mikhail Glushenkov committed 9 years ago

'cabal user-config init' creates a default config file if it doesn't already
exist.

If '--config-file' is set, then that file will be written.

If '-f' or '--force' is used, then the file will be overwritten if it already
exists.

GHC 8.0 is switching the state sponsored way to specify
linker names from -this-package-key to -this-unit-id, so
it behooves us to use the right one.  But it didn't make
much sense to pass ComponentIds to a flag named UnitId,
so I went ahead and finished a (planned) refactoring
to distinguish ComponentIds from UnitIds.

At the moment, there is NO difference between a ComponentId
and a UnitId; they are identical.  But semantically, a
component ID records what sources/flags we chose (giving us enough
information to typecheck a package), whereas a unit ID records
the component ID as well as how holes were instantiated
(giving us enough information to build it.)  MOST code
in the Cabal library wants unit IDs, but there are a few
places (macros and configuration) where we really do
want a component ID.

Some other refactorings that got caught up in here:

    - Changed the type of componentCompatPackageKey to String, reflecting the
      fact that it's not truly a UnitId or ComponentId.

    - Changed the behavior of CURRENT_PACKAGE_KEY to unconditionally
      give the compatibility package key, which is actually what you
      want if you're using it for the template Haskell trick.  I also
      added a CURRENT_COMPONENT_ID macro for the actual component ID,
      which is something that the Cabal test-suite will find useful.

    - Added the correct feature test for GHC 8.0 ("Uses unit IDs").

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

This default is consistent with Cabal.

'DSL.exResolve' now takes a 'Maybe [Extension]' for supported extensions and
a 'Maybe [Language]' for supported languages.  'Nothing' means that
extensions/languages are not checked by the solver, and 'Just []' means that
no extensions/languages are allowed.

No need to test functions that come from the tar lib now.

Also, correct the expected output for sandbox remove source. Previously
the results were expected to come out in reverse order, because the old
filterEntriesM performed the monad actions in reverse order. The new
code doesn't have that bug so the results come out in the correct order.