GitLab

`--dynlibdir` indicates the directory in which dynamic libraries
are installed. By default this setting is equal to:

`$libdir/$abi`

The static libraries will still end up in:

`$libdir/$libsubdir`

With `$libsubdir/$abi` as the default directory for dynamic
libraries, dynamic libraries will by default end up in a
single shared directory (per package database). This has the
potential to reduce start-up times for dynamically linked
executable as only one RPATH per package database will be
needed.

This commit uses the functionality defined in

https://phabricator.haskell.org/D2611

to tell GHC's > 8.0.1 package database that dynamic libraries
are copied to the directories mentioned in the

`dynamic-library-dirs`

field.

[ci skip]

[ci skip]

[ci skip]

Timer osx pr

Avoid generating redundant constraints in new-freeze

Remove support for --assume-deps-up-to-date

Don't register inplace if we're in per-component mode.

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

We sometimes have to union constraints from different places, but we
should simplify those before rendering so we don't add needless
redundancy like "aeson-pretty ==0.8.1 || ==0.8.1". So we just use
simplifyVersionRange after unioning things.

Fixes #4002

Record the result of a slightly tricky debugging session so the next
person gets a head start.

[skip ci]

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

This reverts commit 351c1306.

This reverts commit 85a76c9d.

This reverts commit 1d27ac71.

This reverts commit 2fac2ec6.

This reverts commit 4ea94c45.

This reverts commit c6c3f2c5.

This reverts commit 68891ce4.

This reverts commit 38dc31b2.

This reverts commit 75db3da2.

Generally, the the runner (e.g. new-build) will know
better about the specific package db that the package
should be registered inplace into.  So don't register
into our distdir; it's not useful.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

For non-Custom packages, replace sdist with hand-rolled rebuild checking

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>

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

Re-enable Travis testing other versions of GHC.

Workaround GHC #11214 by filtering JavaScriptFFI

Unfortunately, "native" GHC advertises support for `JavaScriptFFI` even though
it doesn't support it. See also https://ghc.haskell.org/ticket/11214 for respective
bug.

However, in order to properly declare that packages require `JavaScriptFFI` support
via `other-extensions` we need to fixup the list of extensions fed to the cabal solver.

This patch does something similiar to the workaround we added some time ago to
filter out TemplateHaskell for older GHCs which didn't properly advertise
`TemplateHaskell` availability (c.f. 9f68eb44)

This increases our test coverage for using Cabal with GHC 7.0, 7.2
and HEAD.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

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

Add Travis job to build cabal with solver debug flags enabled.

Add explicit osx image to GHC 7.8.4 job

Change the minimum version we use to decide if ghc supports .ghc.env
files. Previously we declared that it required 8.0.2, but 8.0.2 is not
out yet so this makes things hard to test.

It was fixed in the 8.0.x branch at the end of August, so if ghc
declares itself to be 8.0.1.$date from September or later, then it's ok.

This is most of the way there but needs testing in practice with
ghc-8.0.2.

When we invoke ghc in Cabal it's impostant that we control the
environment. It's already the case that ghc ignores the .ghc.env files
when we use -hide-all-packages, but there were a few places where we
were not using this.

This new ghc feature was actually added in ghc 7.10 but very limited,
then extended significantly in 8.0.1 but with a severe bug for our use
case and then should be working fine in 8.0.2 onwards.

This patch adds basic support for writing .ghc.environment files. This
feature will be used later in cabal-install, but it makes sense for the
functionality to live in Cabal next to the other code that knows all
too much about GHC.

.ghc.environment file support works in ghc 8.0.2 onwards

It was actually added in ghc 7.10 but very limited, then extended
significantly in 8.0.1 but with a severe bug for our use case and
then should be working fine in 8.0.2 onwards.