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>

Previously, these flags had no affect on new-build.
Now, they let you specify where the dist-newstyle directory
should go.

Note that if a relative path is provided, it is resolved
relative to the *project root*.  If this is undesirable,
pass an absolute path instead.

Fixes #4127.

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

Fixes #4133

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

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Signed-off-by: Auke Booij <auke@tulcod.com>

See https://ghc.haskell.org/trac/ghc/ticket/7436#comment:6.

This is an edge case. If there is only ever one choice for the next goal, the
solver never evaluates the conflict count map. Additions to the map create a
growing thunk.

See cabal-testsuite/README.md for a detailed description
of the new architecture.

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

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

[skip ci]

This commit moves the utility functions from
UnitTests.Distribution.Solver.Modular.Solver to a new module,
UnitTests.Distribution.Solver.Modular.DSL.TestCaseUtils.

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`

Closes #1613.

Unfortunately, propagating the `Verbosity` to the `topHandler`
proves to be more complicated.

This is mostly a problem for `die` invocations which are translated
into user-error exceptions (which in turn then cause callstacks
to be printed; are we abusing `die`?)

This adds the following new fields:

 - `.compiler-id`
 - `.os`
 - `.arch`
 - `.install-plan[].pkg-name`
 - `.install-plan[].pkg-version`
 - `.install-plan[].pkg-src-sha256`

Having separate "pkg-{name,version}" fields is desirable because the "id"-field
is actually a UnitId which is supposed to be an opaque id which may not
always be easily convertible into a PackageId via string operations.

The "pkg-src-sha256" is generally useful to uniquely identify a
source-tarball (when the package-id is not exact enough).

Finally, the compiler-id/os/arch information is needed to determine the
values of the respective impl()/os()/arch() predicates used in
conditionals in .cabal files.

Here's an example demonstrating the new fields:

    {
      "cabal-version": "1.25.0.0",
      "cabal-lib-version": "1.25.0.0",
      "compiler-id": "ghc-8.0.1",
      "os": "linux",
      "arch": "x86_64",
      "install-plan": [
	{
	  "type": "configured",
	  "id": "StateVar-1.1.0.4-048d5d25d5813f17f152f9e766fe3ea0ef6f5317439aa115f3fc24e53a0e3c17",
	  "pkg-name": "StateVar",
	  "pkg-version": "1.1.0.4",
	  "flags": {},
	  "style": "global",
	  "pkg-src-sha256": "7ad68decb5c9a76f83c95ece5fa13d1b053e4fb1079bd2d3538f6b05014dffb7",
	  "depends": [
	    "base-4.9.0.0",
	    "stm-2.4.4.1-2c7789312d2396a91db173e1ae8cf3a9af3dd18de42bb1021c4978fbab49c191",
	    "transformers-0.5.2.0"
	  ],
	  "exe-depends": [],
	  "component-name": "lib"
	},
        {
          "type": "pre-existing",
          "id": "rts",
          "pkg-name": "rts",
          "pkg-version": "1.0",
          "depends": []
        },
	{
	  "type": "configured",
	  "id": "hackage-matrix-builder3-0.3-inplace-matrix-lib",
	  "pkg-name": "hackage-matrix-builder3",
	  "pkg-version": "0.3",
	  "component-name": "lib:matrix-lib"
	  ...
	}
	...
    }

New error message is:

cabal: Failed to build p-1.0 (which is required by exe:e4 from p-1.0, exe:e3
from p-1.0 and others).

Fixes #4081.

TODO: Use these utility functions in other appropriate places.

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 idea is we can use Rep to get a full, structural representation
of a type, and the fingerprint it using Typeable.  This gives
us a very concise way of fingerprinting our Binary representation.

This patch is not completely correct; the fingerprint needs
to be overridable when someone writes a custom Binary instance.
But this should be "good enough" in practice; we're not using
these fingerprints to check anything security critical.

TODO: Not sure if I have tagged all the call-sites which could
profit from this.

Fixes #4059.

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

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

Before:

    cabal new-build               Build the package in the current
  directory or all packages in the project
    cabal new-build pkgname       Build the package named pkgname in the
  project
    cabal new-build cname       Build the component named cname in the
  project
    cabal new-build pkgname:cname       Build the component named cname
  in the package pkgname

After:

    cabal new-build               Build the package in the current
  directory or all packages in the project
    cabal new-build pkgname       Build the package named pkgname in the
  project
    cabal new-build cname         Build the component named cname in the
  project
    cabal new-build pkgname:cname Build the component named cname in the
  package pkgname

Before:

$ cabal new-configure
Resolving dependencies...
In order, the following would be built (use -v for more details):
 - Crypto-4.2.5.1 (exe:SymmetricTest) (requires build)
 - Crypto-4.2.5.1 (exe:WordListTest) (requires build)
 - Crypto-4.2.5.1 (exe:SHA1Test) (requires build)
 - Crypto-4.2.5.1 (exe:QuickTest) (requires build)
 - Crypto-4.2.5.1 (exe:RSATest) (requires build)
 - Crypto-4.2.5.1 (exe:HMACTest) (requires build)
 - HaXml-1.25.3 (exe:Xtract) (requires build)
 - HaXml-1.25.3 (exe:Validate) (requires build)
 - HaXml-1.25.3 (exe:MkOneOf) (requires build)
 - HaXml-1.25.3 (exe:CanonicaliseLazy) (requires build)
 - HaXml-1.25.3 (exe:Canonicalise) (requires build)
 - HaXml-1.25.3 (exe:XsdToHaskell) (requires build)
 - HaXml-1.25.3 (exe:DtdToHaskell) (requires build)
 - HaXml-1.25.3 (exe:FpMLToHaskell) (requires build)
 - aeson-pretty-0.8.1 (exe:aeson-pretty) (requires build)
 - cpphs-1.20.2 (exe:cpphs) (requires build)
 - hS3-0.5.9 (exe:hs3) (requires build)
 - yaml-0.8.18 (exe:json2yaml) (requires build)
 - yaml-0.8.18 (exe:yaml2json) (requires build)

$ cabal new-build
Resolving dependencies...
Up to date

After:

$ cabal new-configure
Resolving dependencies...
Up to date

$ cabal new-build
Resolving dependencies...
Up to date

    Plain `Dependency` should strictly refer to a Haskell Package, usually the
    library component of that package.

Herbert Valerio Riedel authored 8 years ago and Edward Z. Yang committed 8 years ago

Construction and destruction follows the usual pattern with `mkFlagName`
& `unFlagName` functions.

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

Constrain Cabal >= 1.20 in all new-build install plans. This solves problems where Cabal 1.18 don't have a good enough API to let us handle the new-style store (we need --dependency flags.)

In the future we plan to relax this to only Setup.hs dependencies.

Fixes issue #3932.

A stanza for a platform library looks something like

    platform-library test-package
      type:                native-shared

      if os(Windows)
        options: standalone
        mod-def-file: TestPackage.def

      other-modules:       MyPlatformLib.Hello
                           MyPlatformLib.SomeBindings
      build-depends:       base >=4.7 && <4.9
      hs-source-dirs:      src
      c-sources:           csrc/MyPlatformLibWrapper.c
      default-language:    Haskell2010

where native-shared means that we want to build a native shared library
(.so on Linux, .dylib on OSX, .dll on Windows). The parser also
recognizes native-static but this is not currently supported anywhere.
The standalone option means that the we merge all library dependencies
into the dynamic library (i.e., ghc options -shared -static), rather
than make the created dynamic library just record its dependencies (ghc
options -shared -dynamic); it is currently compulsory on Windows and
unsupported anywhere else. The mod-def-file can be used to specify a
module definition file, and is also Windows specific.

There is a bit of refactoring in Build: gbuild is the old buildOrReplExe
and now deals with both executables and platform libraries.