* This is only enabled with the lib flag.
* We tell users not to use the library in the package description.

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

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.

echo-0.1.3 introduces a dependency on the minimalistic mintty library, so we
need to add that to ./bootstrap.sh as well.

The executable is unused so it shouldn't need to be built and
cause problems.

Also, convert the test to use the testsuite

Fixes #2139.

Modeled after the extern_build_tools test

Ben Gamari authored 8 years ago and Mikhail Glushenkov committed 8 years ago

(cherry picked from commit e0bf43c3)

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

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Auke Booij <auke@tulcod.com>

This commit moves the utility functions from
UnitTests.Distribution.Solver.Modular.Solver to a new module,
UnitTests.Distribution.Solver.Modular.DSL.TestCaseUtils.

Jason Dagit authored 8 years ago and Edward Z. Yang committed 8 years ago

Constrain Cabal >= 1.20 in all new-build install plans. This solves problems where Cabal 1.18 don't have a good enough API to let us handle the new-style store (we need --dependency flags.)

In the future we plan to relax this to only Setup.hs dependencies.

Fixes issue #3932.

In #4017, hvr reported that when he used --allow-older/--allow-newer,
there was an assert failure in toConfiguredComponent.  Indeed
the problem was that toConfiguredComponent was testing version
ranges of build-depends to determine which package to select, but
there was no satisfying one (since the build-depends field had
not been updated.)

After thinking about this for a bit, it seemed a bit bogus for
us to be doing another version check at this late phase; we
already picked dependencies earlier in the configuration process.
So I decided to drop it.

To drop it, however, I needed to remove support for a feature (discussed
in #4020), which uses version ranges to disambiguate whether or not a
dependency is on an external package or an internal package.  This
feature doesn't seem to be very useful.  If someone asks, I'll
check on Hackage to see if anyone is using it.

Also added some useful extra debug info.

Fixes #4020 and #4017

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

When a library/executable is unbuildable, the solver may still
return a reference to it.  Handle this gracefully in ProjectPlanning
with a nice error message, rather than an assert failure.

Fixes #3978.

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

New module Distribution.Client.SourceFiles implements
'needElaboratedConfiguredPackage', which if run in the 'Rebuild'
monad is sufficient to ensure all source files that participate
in a build are monitored.

Fixes #3401.  It also fixes the "we didn't detect a new file
appearing" problem.

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

- No need to add other-modules by hand
- Works on OSX (.sh didn't)
- Found missed files!

This way `cabal` can bootstrap secure repos even if the primary Hackage
instance is currently unreachable, as long as there's at least one
reachable and working secure mirror available.

NB: This new code-path is only used for the initial bootstrap. Once the
repository cache has been bootstrapped, its `mirrors.json` meta-data is
used instead.

See also https://github.com/well-typed/hackage-security/issues/171

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

On recent OS X, Cabal does not work correctly because it assumes
that a permission denied error when reading permissions on
executables, resulting in errors like "Setup: /usr/bin/ar: permission denied".

The proximal fix for this is to add a constraint on unix when we build
Cabal/cabal-install to avoid building with the buggy version of unix.
But this causes other problems:

- Bumping the version of unix means that our local build of Cabal
  will depend on things from the store.  But we weren't passing
  this to GHC when compiled Setup.hs for Cabal's package-tests.
  Set CABAL_PACKAGETESTS_DB_STACK env var explicitly to point
  to the right locations.

- The new configuration of versions exposed some bugs in some
  macro expanded code in cabal-install; we qualified those
  imports to squash unused warnings.

- The cabal-install integration-tests occasionally use Cabal from
  the system GHC.  Since this will never work on OS X, we just
  skip the tests in those cases.

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

We're going to need ProjectPlanOutput to import the ProjectBuilding
types, but this would cause a cycle with ProjectPlanning. So do the same
thing we did with ProjectPlanning and move the types out.

This is supposed to become more or less a superset of Cabal's
`Distribution.Compat.Prelude`.

As a side-effect,t his exposes `Distribution.Compat.Prelude` from the
Cabal library (which may be actually a good thing, as it may be useful
module to Setup.hs writers).

Fwiw, the GHC executables are compiled with full `-rtsopts` as well.
The benefit is that one can use flags such as `-M1G` to limit the heap
space, or profile memory usage via `-hT`.

Most notably, this allows us to provide a custom instance for `Text`