GitLab

In Cabal 1.22.5.0, the semantics of
--disable-profiling/--enable-profiling depend on ordering (because there
is a hack that operates by looking at the current flag assignment and
doing something). In particular, if I specify --enable-library-profiling
--disable-profiling, I end up with library profiling DISABLED.

The fix is that we NEVER pass --enable-profiling or --disable-profiling
to Cabal. At the moment, and according to my historical analysis, Cabal
ONLY uses configProf to affect the effective library/executable
profiling, which means that anything we do with --enable-profiling, we
can do using the library/executable profiling individually. Since these
are always flags for the versions of Cabal library we support, we will
get order invariance. Historical versions have varied on whether or not
setting executable profiling implies library profiling, but if we set
both explicitly this change in behavior doesn't matter.

This patch is difficult to test because the bad profiling flags
can't be induced on an inplace build.  I tested by hand by building
a package that depended on 'distributive' by hand.

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

Previously, the code was inconsistent on whether or not
flags_x_y_z indicated that these flags could be used
up to version x.y.z, or should be used prior to x.y.z.
This commit picks the LATTER and renames everything
consistently this way.  The bonus is that now the names
match up with the conditionals. Yay.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

[ci skip]

Fixes #2214 by adding a `reconfigure` command and invoking it whenever
necessary. The last configure flags used are saved in a
version-independent format so it should never be necessary for the user
to reconfigure manually.

If we were generating Haddock for cabal-install (we're not
currently) these would cause errors.  Make them stop causing
errors.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Removing 'topdown' as a resolver choice means that 'choose' is also
obsolete and so it is removed too.

This implements the flag `--allow-older` which is the analogous to
`--allow-newer` acting on lower bounds.

This also adds a not yet used `AllowOlder` newtype

This is a preparatory refactoring propsed in #3466 for supporting `--allow-older`

(It already was the default for install.)

For both install and new-build.

Fixes #1823.

This adds support for uploading package candidates by introducing a new flag to `cabal upload`,
--candidate. With this flag, `cabal upload` will upload all supplied tarballs as package candidates.
If combined with `--documentation`, the flag can also be used to upload documentation for a package
candidate to hackage.

Fixes #3418

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

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

Duncan Coutts authored Mar 11, 2016 and Mikhail Glushenkov committed Mar 17, 2016

Getters and setters really need to match up.

Detected by parse/print round trip QC tests.

(cherry picked from commit a82af445)

Duncan Coutts authored Feb 16, 2016 and Mikhail Glushenkov committed Mar 17, 2016

This defines the new cabal.project files and introduces the notion of a
project root (and the logic for finding it). Also has support for
implicit projects when no cabal.project file is defined.

Supports both reading and writing project files or fragments. The
printing & parsing round trips correctly. QC tests to follow.

This is a key part of the new nix-local-build branch approach, based
around projects with clear configuration state held in a project file
(or extra files).

This has support for file and dirs as packages within a project,
including by glob. It supports both globs that much match a target, and
optional globs that are allowed to match nothing. It has partial support
for local tarball, remote http tarball and remote source repo packages.

(cherry picked from commit 324b3240)

This increases compile-time (until GHC becomes more clever) but the
generated code is expected to be at least as good (if not better) than
the manually generated code.

While at it, this removes -XCPP usage from all modules touched.

This addresses #3169

This is preparatory work for implementing #3169
it's kept in a different commit in order to facilitate
comparing code-generation.

Before:

    allow-newer: False

After:

    -- allow-newer: False

* Fix parsing of '--allow-newer=foo --allow-newer=bar'.
* Fix './Setup configure --allow-newer --enable-{tests, benchmarks}'.

This gives `cabal-install` the same treatment as
f6428740 did for `Cabal`

Tomas Vestelind authored May 30, 2015 and Mikhail Glushenkov committed Jan 31, 2016

'cabal user-config init' creates a default config file if it doesn't already
exist.

If '--config-file' is set, then that file will be written.

If '-f' or '--force' is used, then the file will be overwritten if it already
exists.

Cabal < 1.12.0 doesn't know about '--enable/disable-executable-dynamic'
or '--enable/disable-library-coverage'.

This is a problem in general, if rare, but it shows up in the
nix-local-build branch more obviously since it always passes all flags,
including defaults (it does this because the defaults should be
determined by the current version, not the older version).