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.

[ci skip]

Edward Z. Yang authored Feb 12, 2017 and Edward Z. Yang committed Feb 13, 2017

In principle, you could get them out by demunging the sourcePackageId,
but it seems more direct to just let people read it out directly.
Use of Maybe ensures we don't write out these fields when they're
the defaults.

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

[ci skip]

Edward Z. Yang authored Feb 11, 2017 and Edward Z. Yang committed Feb 12, 2017

- Report all reexport errors, not just the first one
- Give more information about how the modules are different
- Add quotes and prettify the foramt
- Preserve spaces when reporting errors

The new message looks like this:

Problem with module re-exports:
  - Ambiguous reexport 'Data.Map'
    It could refer to either:
         'containers-0.5.6.2-59326c33e30ec8f6afd574cbac625bbb:Data.Map'
         brought into scope by the build dependency on containers
      or 'containers-dupe-0.1.0.0-2AdbRP7BsOEKELRWSQejuE:Data.Map'
         brought into scope by the build dependency on containers-dupe
    The ambiguity can be resolved by qualifying the
    re-export with a package name.
    The syntax is 'packagename:ModuleName [as NewName]'.
  - The module 'Missing'
    is not exported by any suitable package.
    It occurs in neither the 'exposed-modules' of this package,
    nor any of its 'build-depends' dependencies.
  - The module 'Private'
    is not exported by any suitable package.
    It occurs in neither the 'exposed-modules' of this package,
    nor any of its 'build-depends' dependencies
setup: Configuration failed

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

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

kristenk authored Feb 08, 2017 and Mikhail Glushenkov committed Feb 10, 2017

Old output:
dependencies not linked: stanza TestStanzas incompatible;
dependencies not linked: flag FlagName "parsec" incompatible

New output:
dependencies not linked: stanza "test" incompatible;
dependencies not linked: flag "parsec" incompatible;

GHC's stage0 build doesn't provide MIN_VERSION_* macros. We need to take care to
provide appropriate version check macros by hand in GHC's build system.

Backpack improvements

Duncan Coutts authored Oct 22, 2016 and Edward Z. Yang committed Feb 07, 2017

It's really an error to try and build a graph where you have duplicate
node keys, so remove Graph.fromList and add Graph.fromDistinctList. This
check is always on, not just an assertion, becuase we get it for free
given the way Maps can be constructed.

All uses of Graph.fromList are ok to convert to fromDistinctList.

Previously, it would incorrectly report that we were
using incompatible versions of a package, if a package
showed up multiple times in Backpack.

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

Now it looks like:

Configuring component lib:str-bytestring-lazy from str-bytestring-0.1.0.0
Instantiated with:
  Data.ByteString=bytestring-0.10.8.1:Data.ByteString
  Data.ByteString.Elem=bytestring-elem-0.1.0.0-inplace:Data.ByteString.Elem
  Data.ByteString.Lazy=bytestring-0.10.8.1:Data.ByteString.Lazy

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

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

Edward Z. Yang authored Jan 22, 2017 and Edward Z. Yang committed Feb 07, 2017

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

Benno Fünfstück authored Jan 27, 2017 and Edward Z. Yang committed Feb 05, 2017

The detailed-0.9 test suite type compiles the test module into a shared library,
so for running the tests, we need to include the directory where the shared
library is stored in LD_LIBRARY_PATH.

Fix deprecation warnings from containers

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

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

kristenk authored Jan 29, 2017 and Edward Z. Yang committed Feb 03, 2017

For example, "setup.Cabal installed" forces cabal to use the installed Cabal
library for all setup scripts.

kristenk authored Jan 29, 2017 and Edward Z. Yang committed Feb 03, 2017

For example, --constraint="any.pkg == 5" applies to "pkg" whether it is a
top-level dependency, setup dependency, or build tool dependency.

I also modified the UserConstraint type so that it is more similar to the
PackageConstraint type, now that both types need to express similar
"constraint scopes".

kristenk authored Jan 22, 2017 and Edward Z. Yang committed Feb 03, 2017

I used the new constraint scope to enforce the minimum Cabal version in setup
scripts that lack a 'custom-setup' stanza.  It isn't exposed to users yet.

kristenk authored Jan 22, 2017 and Edward Z. Yang committed Feb 03, 2017

This commit changes the meaning of constraints like 'pkg > 5'. Previously,
'pkg > 5' only applied to the top-level 'pkg' goal without a 'Namespace', but
now it applies to any top-level goal for 'pkg'. However, the 'Namespace' field is
currently only used by --independent-goals, so this change has no effect on
behavior.

This papers over the differences between Data.Map in containers
0.4.* and Data.Map.Strict in containers 0.5.*.