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 9 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 9 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)

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.

Fixes #3059.

cabal's handling of non-existent sources depends on the behavior of the
directory package. 'canonicalizePath' can fail on non-existent paths before
directory-1.2.3.0. This commit updates the test 'fail_on_nonexistent_source' to
allow 'cabal sandbox delete-source' to fail or succeed.  It also changes
'fail_removing_source_thats_not_registered' so that it only tests existing
sources.

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.

[ci skip]

[ci skip]

Spaces in the path to ghc-pkg caused two tests to fail when run with the
Haskell Platform on Windows.

Needed because cabal-install no longer compiles against Cabal-1.23.1 snapshot
that came with GHC 8.

Lines beginning with "RE:" are regular expressions, and other lines are exact
matches.

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

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

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

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.