GitLab

Add --enable-split-sections flag and pipe it through to the GHC backend. Note
that some of the implementation here could be made a bit more precise:
-split-sections and -split-objs are mutually exlusive yet the types don't
currently reflect this.

Fixes #4819.

new-update uses the new-style logic to update the repositories.  As such it
respects `repository` fields in the `cabal.project(.local)` file and updates
them as well.  This is essential when working with hackage overlays, where
the overlay repositories are specified as `repository` fields in the
`cabal.project(.local)` file.

This removes the redundancy between `RelaxDepsNone` and
`RelaxDepsSome []` by removing `RelaxDepsNone`.

This way we avoid the risk of subtle bugs that can occur if the same
semantic value can be expressed in a non-unique way.

A further step to normalise the type would be to turn `[RelaxedDep]`
into `Set RelaxedDep`, but there is no operation that would
significantly benefit from that yet.

This appears to be somewhat redundant, since there's also the
SetupWrapper hack in place which also filters out `+timestamp` for
externally invoked commands other than `configure`, but it's "good
style" to keep `filterConfigureFlags` in sync for the sake of
consistency.

This is a preparatory refactoring needed for future work such as #4203.

I've refrained from doing additional cleanups in order to keep this a
refactoring that mostly moves around blocks of code mostly
unchanged (except for whitespace), and make it easier to review.

This feature was originally implemented because its lack was complained
about by Stack/Stackage developers. However, after it got implemented it
was never really being used; what's more, it's causing us overhead for
no benefit as well as blocking us improving the implementation via the
likes of #4203.

Closes #3581

--independent-goals could be useful for using local packages as setup or
build-tool dependencies in new-build.  See #4295 for an example of a dependency
problem that requires --independent-goals.  The flag is off by default.

This adds the `doctest` command to cabal.  It does however not yet work as the driver
is baiscally a stub.

This is therfore only the first step towards #2327.

In particular, the Cmd* modules don't mappend in the defaults
before using the flags, so ensuring they're setup correctly from
the start helps avoid errors.

This default flag business is extremely dodgy and I wish we had a better
story for it.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

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

So far they just build the exe bench and don't do the next steps,
but they do at least select the right components to build.

Also bring the existing test command into sync with the others.

Rather than having it appear in the [other] section. I've just guessed
at where it ought to go. Suggestions welcome.

This implements a bare-bones skeleton for cabal new-exec.

The old cabal exec gave programs access to a sandbox's package database.
By analogy, cabal new-exec should give programs access to the store's
package database; however, this database will be cluttered with many
non-project-related packages that may confuse issues. Therefore new-exec
selects just the packages that are in the current project's dependency
tree and makes them available to compiler tools. Currently only very new
GHCs are supported, via the GHC_ENVIRONMENT mechanism for selecting a
subset of some package databases.

Eventually we should probably also modify the PATH so that dependencies'
executables are available.

Edward Z. Yang authored Feb 18, 2017 and Edward Z. Yang committed Feb 24, 2017

The strategy is to save an 01-index.timestamp file that remembers
what --index-state the user requested during cabal update.
Subsequently, we use that index state if no more precise
index state was specified (via the flag or a project config.)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Edward Z. Yang authored Feb 16, 2017 and Edward Z. Yang committed Feb 19, 2017

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

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

Now if you say cabal -v"info +callstacks", Cabal invocations
will also get call stacks.

There's a heinous hack to handle version of Cabal that don't
support the extended format.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Mikhail Glushenkov authored Jan 05, 2017 and Mikhail Glushenkov committed Jan 17, 2017

Fixes #2139.

--install-base-libraries makes cabal ignore the list of packages that cannot be
installed or upgraded.

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

This is a global flag, so it can only be specified prior to the
subcommand.  It controls the name of the cabal.project file which
new-build and related commands looks for.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

With this `cabal get` gains the ability to

 a) unpack and update with the .cabal revision which was
    active at the given index-state, as well as

 b) allow to unpack the most recent package version
    (while satisfying imposed version constraints) as of
    the given index-state

The `--index-state` flag can be combined with `--pristine` if only b) is
desired.

Also gets rid of `Distribution.Packages.TextClass`

`--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.

Similiar to dabd9d98 which made
`PackageName` opaque, this makes `Distribution.Version.Version` opaque.

The most common version numbers occuring on Hackage are 3- and
4-part versions. This results in significant Heap overhead due to
`Data.Version`'s inefficient internal representation.

So like the `PackageName` commit, this commit is a preparatory commit to
pave the way for replacing `Version`'s internal representation by a
representation with a memory footprint which can be an order of
magnitude smaller.

Finally, this also adds a new functor-like convenience function

    alterVersion :: ([Int] -> [Int]) -> Version -> Version

for modifying the version number components.