Oleg Grenrus authored 6 years ago and Mikhail Glushenkov committed 6 years ago

Remove unix constraint from cabal.project

(cherry picked from commit 6797a9e5)

- Disable cabal-install's haddock on CI
- Temporarily disable cabal check (`-main-is` in tests)
- Remove this is not a lib note
- Tell to run git update-index --assume-unchanged

    ... when changing to -dev or -monolithic configuration.

    Run --no-assume-unchanged unconditionally, when
    changing to the production build.
- Improve auto-gen note in cabal-install.cabal
- Try to build haddock (with GHC-8.4.3 only)

Oleg Grenrus authored 7 years ago and Mikhail Glushenkov committed 7 years ago

(cherry picked from commit 9dde6816)

This script contains similar commands to appveyor.yml, except it relies
on cabal new-build, so should be safe to run locally.

Using this script can ease Travis stress.

ATM I see following tests failing:

- PackageTests/Backpack/Includes3/setup-external-ok.test.hs
    - https://github.com/haskell/cabal/issues/5039
- PackageTests/CustomPlain/setup.test.hs
    - `<command line>: cannot satisfy -package-id Cabal-2.1.0.0-inplace`
- PackageTests/CustomDep/sandbox.test.hs
    - `.../dist-sandbox-3402c05b/setup/setup: createProcess: runInteractiveProcess: exec: permission denied (Permission denied)`

Also undo a change committed by mistake.

[ci skip]

The issue is fixed now.

Should unbork the test suite.

This benchmark is based off of a script written by @kosmikus.  It adds
functionality for running multiple trials for each package, but it is currently
missing other features.

Committed by accident as part of
45fb7929.

[ci skip]

See #4462 for the gory details.

Main things about this commit:

- New 'monolithic' flag on cabal-install, which combines
  all of the tests into a single binary.  It's not very
  much code, and you don't pay for any of it on a release
  build.  I quite like it.  The one downside is that
  we can't also pull in Cabal test suites this way.

- Env vars got moved into travis-common.sh

- travis-script.sh now runs the cabal-tests tests, because
  we aren't sending enough build product over to do them
  on the second Travis run

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

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

See #4497 for more details. We'll have to set this bound
until tasty fixes the bug.

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

* 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 48c6f00b.

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

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

The key idea is that once we put PackageTests in its own package, we can
ensure that its Setup.hs is compiled with the same version of Cabal
library as package-tests is compiled with.  This means that LBI reading
will *always succeed* which is quite nice.

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

For the moment we cannot use ghc-options at the top level in the
cabal.project since it applies to all packages not just local ones.
Until that is fixed, use a workaround of specifying it for the two
local packages of interest directly.

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>

This was causing serious performance regression in the solver
so I'm commenting thise one out; see #3911 for details.

[skip ci]

Always in the tests, and also for devs in the cabal.project