GitLab

This reverts commit 7f061f5d.

[ci skip]

[ci skip]

This reverts commit e7d2a62c due to a
bug.

The package databases obtained from GHC_PACKAGE_PATH should be stored in
the LocalBuildInfo and passed to GHC when necessary; otherwise, the user
could change GHC_PACKAGE_PATH causing GHC and Cabal to see inconsistent
installed package sets. cabal-install should trigger reconfiguration if
GHC_PACKAGE_PATH changes.

This patch uses CallStack support in GHC 7.10 and GHC 8.0 to make
it possible to get stack traces when we log output.

This is the bare minimum to make this patch useful: there is
plenty of tuning that can be done.  For example:

* Insertions of withFrozenCallStack can help make the "callsite" output
  more useful, though be careful, we lose all stack information at that point!

* Insertions of 'WithVerbosity', which will let us get deeper stacks
  (at the moment, they are basically always 1-deep.)

Fixes #3768.

CC @23Skidoo

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

This implements a new syntactic sugar: The version range operator
`^>=` which is equivalent to `>=` intersected with an
automatically inferred major upper bound.

This new syntax is only allowed for `cabal-version: >=2.0`, and
allows to describe the most common use of version
bounds more conveniently:

    build-depends: foo ^>= 1.2.3.4,
                   bar ^>= 1

The declaration above is exactly equivalent to

    build-depends: foo >= 1.2.3.4 && < 1.3,
                   bar >= 1 && < 1.1

This also helps with the issue of the wildcard operator having the
surprising effect that e.g. `== 1.0.*` does not include the single 
digit version `1`.

The `^`-symbol was chosen because it can serve as a mnemonic when the
`>` sign is rotated and interpreted as "less than ceiling"

Moreover, `^` appears to become a quasi-standard to denote morally
equivalent operator that way in other language ecosystems which similiar
to Haskell have adopted semantic versioning:

 - Node: https://nodesource.com/blog/semver-tilde-and-caret/
 - Bower: https://bower.io/docs/api/#install
 - PHP: https://getcomposer.org/doc/articles/versions.md#caret

Ruby, on the other hand, uses a Tilde operator (`~>`) for that
purpose (but with a less robust semantic):

 - https://blog.codeship.com/optimists-guide-pessimistic-library-versioning

And Python is currently planing to use an `~=` operator:

 - https://www.python.org/dev/peps/pep-0440/#compatible-release

Fixes #3728. Fixes #2711.

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

Described in: https://github.com/ghc-proposals/ghc-proposals/pull/4



./Setup configure now takes an argument to specify a specific
component name that should solely be configured.

Most of the gyrations in Configure are all about making it so that
we can feed in internal dependencies via --dependency.

I dropped the package name match sanity check to handle convenience
library package name munging.  Consider an internal library named
'q' in package 'p'.  When we install it to the package database,
we munged the package name into 'z-p-z-q', so that it doesn't
conflict with the actual package named 'q'.  Now consider when
we feed it in with --dependency q=p-0.1-hash-q.  Previously,
Cabal checked that the 'q' in --dependency matched the package
name in the database... which it doesn't. So I dropped the check.

I also had to make register/copy unconditionally install internal
libraries; otherwise you can't refer to them from later builds.

Also a miscellaneous refactor: convenience libraries are printed with a
"header" stanza now (not really a stanza header).
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

I also realized LOCAL_COMPONENT_ID is pessimal if we don't
depend on a library, so I removed it. (It has never been
in a real Cabal release.)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

[ci skip]

Modules that are built automatically at setup, like Paths_PACKAGENAME or others created with a build-type custom, appear on 'other-modules' for the Library, Executable, Test-Suite or Benchmark stanzas or also on 'exposed-modules' for libraries but are not really on the package when distributed. This makes commands like sdist fail because the file is not found, so with this new field modules that appear there are treated the same way as Paths_PACKAGENAME was and there is no need to create complex build hooks.
Just add the module names on 'other-modules' and 'exposed-modules' as always and on the new 'autogen-modules' besides.

This is an omnibus patch, with the overall goal of making
LocalBuildInfo Great Again.  The essential ideas:

* New type 'TargetInfo' which bundles together 'ComponentLocalBuildInfo'
  and 'Component'.  Eventually, it will also record file paths / module
  targets.  This data structure is basically what you want; a lot of
  old Cabal code did lots of gyrations converting from
  'ComponentLocalBuildInfo' to 'Component' and vice versa, now
  it's all centralized.

* The "new" API for 'LocalBuildInfo' is in
  "Distribution.Types.LocalBuildInfo".  The general principle
  is, where we previous dealt in 'ComponentLocalBuildInfo',
  we now deal in 'TargetInfo'.  There are shockingly few
  functions we need!

* I've restored 'componentsConfigs' to its Cabal 1.24 signature
  for BC.

* I killed a number of unused functions from "Distribution.Simple.LocalBuildInfo":
  'getLocalComponent', 'maybeGetDefaultLibraryLocalBuildInfo',
  'maybeGetComponentLocalBuildInfo', 'checkComponentsCyclic' and
  'enabledComponents'.  For each I checked on Hackage that they were
  not used.

* 'getComponentLocalBuildInfo', 'withComponentsInBuildOrder' and
  'componentsInBuildOrder' are deprecated to encourage people
  to instead use the 'TargetInfo's to finger which components
  they want built.

* 'ComponentLocalBuildInfo' now stores internally the computed
  'componentInternalDeps', so that 'LocalBuildInfo' can simply store
  a graph of 'ComponentLocalBuildInfo'.

* The code in Configure has been streamlined to use our new Graph
  data type to great success.

* The type of 'runTest' changed to take a 'ComponentLocalBuildInfo',
  bringing it more in line with everything else.

* New function 'readTargetInfos' which combines 'readBuildTargets'
  and 'checkBuildTargets', which is what you really wanted anyway.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

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

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

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

As per an existing TODO in the code, the use of
testEnabled/benchmarkEnabled to indicate if a component
was enabled/disabled by the user command line was an
egregious violation of abstraction.  This commit removes
these two fields, instead passing along the necessary
enabling information with ComponentEnabledSpec instead.

As there were not many uses of testEnabled/benchmarkEnabled,
this was not too difficult to do.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

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

[ci skip]

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

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

Fixes #3229.
(cherry picked from commit 7ab167b8)

(cherry picked from commit 9cd1387fcd582a6131746e6742597069d54f905a)

* Renamed to 'extra-framework-dirs'.
* Added 'extra-framework-dirs' to ConfigFlags.
* Added some checks.
* Updated changelog.

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

This mode implements #2911, and allows to connect the test runner
directly to stdout/stdin. This is more reliable in the presence of no
threading, i.e. a work-arond for #2398.

I make the test suite use this, so that it passes again, despite
printing lots of stuff. Once #2398 is fixed properly, the test suite
should probably be extended to test all the various --show-details
modes.

This reverts commit bd7bbd70, reversing
changes made to d8fa4618.

This fixes #2689.

ttuegel authored Apr 25, 2015 and Duncan Coutts committed Jul 02, 2015

Conflicts:
	Cabal/changelog

Fixes #2484. The 'builddir' option may now be specified in cabal.config
as well. It will also be read from the CABAL_BUILDDIR environment
variable, if set. The order of precedence (highest to lowest) is:
1. --builddir command line option
2. CABAL_BUILDDIR environment variable
3. cabal.config setting