GitLab

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

So we can use them in binary cache files.

Also relax version constraints on binary to work with binary-0.5.*,
which requires that we expose Distribution.Compat.Binary from Cabal.

D.Compat.Binary provides the Gerics support that we need to be able to
derive instances when using binary-0.5. It's useful to be able to use
binary-0.5 since that's the version bundled with older ghc versions.

Also rename it to '--documentation'. Note that the shorthand still works.

The RepoContext encapsulates the list of repositories, as well as some
associated state. In particular, it also encapsulates the HttpTransport, which
will be initialized on demand and cached thereafter.  This is important for two
reasons:

* For the hackage-security integration: in order to be able to use cabal's own
  HttpTransport API for the secure repo, we need to have access to that
  transport when we initialize the repo, but as things stood that was not
  possible (cabal was initializing repos ahead of time but the transport on
  demand).

* For the integration with the nix-local-branch it is important that the Repo
  type remains Serializable. By passing RepoContext rather than a list of
  Repos, we can leave RepoSecure serializable and separately maintain a mapping
  from cabal's Repo type to hackage-security's (stateful) Repository type.

This is in preparation for the next commit (and will avoid circular
module dependencies).

If used, this will instruct the hackage-security library to ignore expiry dates
on TUF metadata (to be used only if, say, the main server is down and we need
to rely on mirrors that have not been updated for longer than the expiry period
on the timestamp).

In other words, give it a callback, changing the type from

    globalRepos :: GlobalFlags -> [Repo]

to

    Verbosity -> GlobalFlags -> ([Repo] -> IO a) -> IO a

This will be necessary for repositories that need to do some
repository-specific initialization (even if we don't currently have any, we
will soon). The Verbosity flag is not used yet, but will be.

This just changes the type and deals with the fallout.

The old Repo type has a repoKind

    repoKind     :: Either RemoteRepo LocalRepo,

where LocalRepo was isomorphic to unit:

    data LocalRepo = LocalRepo

This commit changes Repo to

    data Repo =
        -- | Local repositories
        RepoLocal {
            repoLocalDir :: FilePath
          }

        -- | Standard (unsecured) remote repositores
      | RepoRemote {
            repoRemote   :: RemoteRepo
          , repoLocalDir :: FilePath
          }

instead, which is a little more idiomatic and will make adding more repository
types easier.

This extends `RemoteRepo` with new fields

``` haskell
-- | Enable secure access to Hackage?
remoteRepoSecure :: Bool,

-- | Root key IDs (for bootstrapping)
remoteRepoRootKeys :: [String],

-- | Threshold for verification during bootstrapping
remoteRepoKeyThreshold :: Int,
```

and modifies the parser accordingly. This does not yet require a dependency on
the security library.

NOTE: We suggest to make the security functionality opt-in, rather than
opt-out, for the first official release. Thus, the 'secure' field will be set
to 'False' when initializing a `~/.cabal/config` file, and existing
`~/.cabal/config` files will be interpreted as if they had `secure: False`.

In the definition of `globalCommand` we had

    (case showOrParseArgs of ShowArgs -> take 8; ParseArgs -> id) [..]

the intention here is that the first 8 options will be shown when the user asks
for `--help`, and the rest are not. However, this is rather error prone. If we
forget to update that value when adding a new command line argument, we might
either be wondering why the option isn't showing in the help text,
or--worse--push another flag out of the help text without noticing.

This commit changes this to

    args ShowArgs  = argsShown
    args ParseArgs = argsShown ++ argsNotShown

    argsShown    = [..]
    argsNotShown = [..]

which is a lot more robust.

This will build (if not given as argument) a doc tarball and upload it to
hackage.

Closes #2080

Today in Cabal, when you build and install a package, it is
uniquely identified using an InstalledPackageId which is computed
using the ABI hash of the library that was installed.  There
are few problems with doing it this way:

    - In a Nix-like world, we should instead uniquely identify
      build products by some sort of hash on the inputs to the
      compilation (source files, dependencies, flags).  The ABI
      hash doesn't capture any of this!

    - An InstalledPackageId suggests that we can uniquely identify
      build products by hashing the source and dependencies of
      a package as a whole.  But Cabal packages contain many components:
      a library, test suite, executables, etc.  Currently, when
      we say InstalledPackageId, we are really just talking about
      the dependencies of the library; however, this is unacceptable
      if a Cabal package can install multiple libraries; we need
      different identifiers for each.

    - We've also needed to compute another ID, which we've called
      the "package key", which is to be used for linker symbols
      and type equality GHC-side.  It is confusing what the distinction
      between this ID and InstalledPackageIds are; the main reason
      we needed another ID was because the package key was needed
      prior to compilation, whereas the ABI hash was only available
      afterwards.

This patch replaces InstalledPackageId and PackageKey with a
new identifier called ComponentId, which has the following
properties:

    - It is computed per-component, and consists of a package
      name, package version, hash of the ComponentIds
      of the dependencies it is built against, and the name
      of the component.  For example, "foo-0.1-abcdef" continues
      to identify the library of package foo-0.1, but
      "foo-0.1-123455-foo.exe" would identify the executable,
      and "foo-0.1-abcdef-bar" would identify a private sub-library
      named bar.

    - It is passed to GHC to be used for linker symbols and
      type equality.  So as far as GHC is concerned, this is
      the end-all be-all identifier.

    - Cabal the library has a simple, default routine for computing
      a ComponentId which DOES NOT hash source code;
      in a later patch Duncan is working on, cabal-install can
      specify a more detailed ComponentId for a package
      to be built with.

Here are some knock-on effects:

    - 'id' is a ComponentId

    - 'depends' is now a list of ComponentIds

    - New 'abi' field to record what the ABI of a unit is (as it is no longer
      computed by looking at the output of ghc --abi-hash).

    - The 'HasInstalledPackageId' typeclass is renamed to
      'HasComponentId'.

    - GHC 7.10 has explicit compatibility handling with
      a 'compatPackageKey' (an 'ComponentId') which is
      in a compatible format.  The value of this is read out
      from the 'key' field.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This commit adds the sources of constraints to debugging and error messages,
e.g., "main config file" or "command line flag".

New flags: --profiling-detail and --library-profiling-detail.
When profiling is enabled (by the existing flags) then these flags
are taken into account to set the profiling detail level.

The levels are:
 none
 default
 exported-functions
 toplevel-functions
 all-functions

The default value for ghc for libraries is exported-functions and
for exes is toplevel-functions.

On GHC these levels correspond to the -fprof-auto* flags. The
ghc-prof-options will override this (just because it's passed to
ghc at the end).

The initial patch would always try to use HTTPS, even when the repo
specified to use HTTP. This works for the central community hackage
but obviously does not work in general.

The new logic is that we always follow what is specified for the
remote repo in the config, except for built-in known repos (currently
just the central community hackage) where we mark them as also
supporting https. For upload when uploading to such a marked repo
then we will try https and will complain if the plain-http impl was
selected automatically (but it's ok if selected manually).

This patch also changes things so that for http urls on download, we
stick to the builtin http impl by default, and only use the external
ones if https support is required (i.e. because the repo was
configured to use an https url)

Move utils into other Util modules.
Reformat all code to 80 cols.
Reorder code and add more comments.
Use long form style program args, e.g. --silent rather than -s
Finish implementation of form upload with wget
Fix reporting of server error messages for upload (curl & builtin)
Implement collecting of ETags for curl and wget.
Fix wget for case of 304 not modified response (wget uses exit code 8).
Rework transport configuration phase.

U-CIQDEV\gbazerman authored May 01, 2015 and Duncan Coutts committed Jun 29, 2015

Supports both uploading and downloading.
Basic built-in HTTP is still supported.

This fixes issues when the version of Cabal that cabal-install was built
against differs from the one registered in the local package DB. Normally
we compile an external setup against the local Cabal library, which could
lead to failures or inconsistent results compared to using the internal
method.

This fixes #2438 and fixes #1938.