This project is mirrored from Pull mirroring updated .
  1. 17 Dec, 2015 9 commits
    • bardur.arantsson's avatar
    • Mikhail Glushenkov's avatar
      Merge pull request #2949 from edsko/pr/more-types · 121cbf1c
      Mikhail Glushenkov authored
      Type refactoring
    • Herbert Valerio Riedel's avatar
      Merge pull request #2955 from bgamari/master · 5e1d33dd
      Herbert Valerio Riedel authored
      Program.Find: Fix on Win32
    • Ben Gamari's avatar
      Program.Find: Fix on Win32 · e275a162
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      ee0ed0b9 added another codepath to
      Distribution.Simple.Program.Find for Win32 platforms however did not add
      correct imports or a dependency on the Win32 library. Fix this.
    • Edsko de Vries's avatar
      Address comments on #2949. · ef6fe247
      Edsko de Vries authored
      This changes the definition of `Index` to
      ``` haskell
      data Index =
          -- | The main index for the specified repository
          RepoIndex Repo
          -- | A sandbox-local repository
          -- Argument is the location of the index file
        | SandboxIndex FilePath
      cacheFile (SandboxIndex index) = index `replaceExtension` "cache"
      This also renames `repoRemote'` to `maybeRepoRemote`.
      I believe this addresses all comments.
    • Edsko de Vries's avatar
      Change globalRepos to withGlobalRepos · a301b156
      Edsko de Vries authored
      In other words, give it a callback, changing the type from
          globalRepos :: GlobalFlags -> [Repo]
          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.
    • Edsko de Vries's avatar
      Change Repo type · a8056d47
      Edsko de Vries authored
      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.
    • Edsko de Vries's avatar
      Introduce datatype for the Cabal index cache · 2cce2cb8
      Edsko de Vries authored
      Right now this just wraps the list of cache entries, but this might make it
      easier in the future to change the structure of the cache.
    • Edsko de Vries's avatar
      Introduce structured type for specifying index · 99454f73
      Edsko de Vries authored
      In particular, distinguish between the repo-global index and a (sandbox-)local
  2. 16 Dec, 2015 31 commits
    • Herbert Valerio Riedel's avatar
      Make Distribution.Simple.Configure warning-free & CPP-free · 4e33454f
      Herbert Valerio Riedel authored
      GHC 8.0 changed the `ErrorCall` type to have an extended constructor,
      and backward compatibility has been provided via PatternSynonyms:
          data ErrorCall = ErrorCallWithLocation String String
              deriving (Eq, Ord)
          pattern ErrorCall :: String -> ErrorCall
          pattern ErrorCall err <- ErrorCallWithLocation err _ where
                  ErrorCall err  = ErrorCallWithLocation err ""
      However, due to the
      exhaustive-checker doesn't cope well with pattern-synonyms yet, and so
      we get a non-exhaustive pattern-match failure when matching on
      'ErrorCall' now.
      As the matching on the constructor 'ErrorCall' is done here to help
      infer the Exception instance, we can also just annotate the type
      directly, and eschew the problematic pattern match.
      While at it, this commit also makes this module CPP-free.
    • Mikhail Glushenkov's avatar
      Changelog update. · 81f98998
      Mikhail Glushenkov authored
    • Duncan Coutts's avatar
      Merge pull request #2948 from dcoutts/cabal-lib-for-nix-local-build · d71de1d4
      Duncan Coutts authored
      Cabal lib for nix local build
    • Mikhail Glushenkov's avatar
      Merge pull request #2951 from edsko/pr/extend-security-config · f616ff0a
      Mikhail Glushenkov authored
      Extend repo config with security settings
    • Mikhail Glushenkov's avatar
      Merge pull request #2950 from edsko/pr/args-shown-vs-not-shown · bf7cd530
      Mikhail Glushenkov authored
      Remove magic value from `globalCommand`
    • Duncan Coutts's avatar
    • Duncan Coutts's avatar
      Add a few comments explaining implementation assumptions · 4164e015
      Duncan Coutts authored
      About the ghc package dbs in particular.
    • Duncan Coutts's avatar
      Add a comment to explain the HcPkg.recache trick · 3761cf4e
      Duncan Coutts authored
      For supporting multi instance registrations on older GHC versions.
    • Edsko de Vries's avatar
      Extend repo config with security settings · 0d9226d6
      Edsko de Vries authored
      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`.
    • Edsko de Vries's avatar
      Remove magic value from `globalCommand` · 7be7efdd
      Edsko de Vries authored
      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.
    • Duncan Coutts's avatar
      Further CPP fix · fc1a23f8
      Duncan Coutts authored
      For some reason my cpp does not fail with #if THING_NOT_DEFINED
      but the travis one does, so use #ifdef instead.
    • Duncan Coutts's avatar
      Fix bootstrapping CPP problem · adcfe14f
      Duncan Coutts authored
    • Duncan Coutts's avatar
      Adjust instance Binary ProgramDb to include the ProgramSearchPath · 96a010ab
      Duncan Coutts authored
      The ProgramDb Binary instance is a bit odd by leaving out the Programs,
      only including the ConfiguredPrograms. Of course this is because the
      Programs contain functions. But the ProgramSearchPath is concrete and
      should be included.
    • Duncan Coutts's avatar
      Extend ConfiguredProgram with search locations looked at · b39b906d
      Duncan Coutts authored
      This is to allow monitoring programs for changes. The combination of the
      location where the program was found, and all the other locations where
      the program was looked for gives the full set of files to monitor for
      changes in that program.
      The Program programFindLocation method is extended to return the
      locations looked at but where the prog was not found. The default
      implementation of programFindLocation, findProgramOnSearchPath, is
      extended to return those locations.
      Other places have to change, mostly just the type. In a couple places in
      GHC & GHCJS where there is additional searching done, the not-found
      locations have to be collected and returned.
    • Duncan Coutts's avatar
      Generalise findProgramOnSearchPath to calculate locations looked in · ee0ed0b9
      Duncan Coutts authored
      But in this patch, don't actually return them yet, so not yet changing
      the resturn type.
      The purpose here is change monitoring. In cabal-install we want to be
      able to automatically re-run various actions when the build environment
      changes, including when programs have changed (e.g. due to a $PATH
      change, finding the compiler in a different location). The basic
      information required for such change monitoring is not only the location
      where a program was ultimately found, but all the locations where it was
      looked for and not found. Otherwise one will miss the case where having
      previously found the program in one location, later on the program
      appears earlier in the search path. In this case a build system should
      notice and react, but if it only monitors the ultimate location where
      the program was found then this is impossible. The build system also
      needs to monitor the locations where the program was not found, to make
      sure it is still not there. This principle actually applies anytime we
      have a file search (e.g. hs-source-dirs), programs are just one example.
    • Duncan Coutts's avatar
      Be consistent about using findProgramOnSearchPath · 7d4fbb26
      Duncan Coutts authored
      The findProgramOnSearchPath function is what we use in most places to
      implement the Program abstraction's programFindLocation method.
      Re-export it via Program module.
      The only place that was still using the old findProgramLocation
      instead was in HaskellSuite. Deprecate findProgramLocation which
      is now no longer used.
      This is in preparation for changing the return type of
    • Duncan Coutts's avatar
      Add new getInstalledPackagesMonitorFiles · 7e409fcb
      Duncan Coutts authored
      It provides a way to find out what files need to be monitored to detect
      changes in a compiler's package database.
      This is not used within the Cabal lib.
    • Duncan Coutts's avatar
      Export a command line unescaping utility · 3ff32fc3
      Duncan Coutts authored
    • Duncan Coutts's avatar
      Add mutli-instance support to registerPackage · 2d0a8781
      Duncan Coutts authored
      With support for GHC and GHCJS. All Cabal lib internal uses remain
      traditional single instance, so there's no change of behaviour.
    • Duncan Coutts's avatar
      Add new HcPkg.registerMultiInstance · 7b4df7e0
      Duncan Coutts authored
      This supports the feature of newer ghc-pkg version which have the
      register --enable-multi-instance flag. This allows registering multiple
      instances of the same version of a package into a single database.
      In addition, to support the same feature on some older ghc-pkg versions,
      the HcPkgInfo has a recacheMultiInstance capability, which tells us if
      the trick of registering multiple instances by running ghc-pkg recache
      works. This is known to work for all versions of ghc-pkg that support
      the recache command at all.
      Then HcPkg.registerMultiInstance will use one of the two methods
      depending on which is supported, or fail if neither is. Currently only
      registering into specific package dbs is supported, not global or user.
      This new multi-instance feature is needed for cabal-install.
    • Duncan Coutts's avatar
      Add internal support for hc-pkg recache and --enable-multi-instance · ae78ae05
      Duncan Coutts authored
      Invocation support but not used yet.
    • Duncan Coutts's avatar
      Extend HcPkgInfo for mulit-package instances capabilities · 728fdcf7
      Duncan Coutts authored
      Part 1: just add the fields and fill them in for each HcPkg user.
    • Duncan Coutts's avatar
      Factor impl of registerInvocation' slightly · b54f36a7
      Duncan Coutts authored
      Prior to further extension. Just share the common args calculation.
    • Duncan Coutts's avatar
      Use the new package db utils to simplify createInternalPackageDB · e86851d7
      Duncan Coutts authored
      And fix up the db path for UHC. UHC cannot just register anywhere, like
      compilers that have a hc-pkg can. It has to be special locations. Now
      that registerPackage no longer takes the inplace :: Bool arg, UHC's impl
      of registerPackage has to get the dir from the PackageDbStack without
      knowing if it's implace or not. So the correct inplace location has to
      be set earlier for the inplace package db, which is what this does.
    • Duncan Coutts's avatar
      Add new compiler independent package db utils · ea6dabe1
      Duncan Coutts authored
      Add doesPackageDBExist and deletePackageDB, and export the new
      createPackageDB. This gives a more complete compiler-independent API for
      package db manipulation.
    • Duncan Coutts's avatar
      Extend HcPkg.init support for dir-style package dbs · 12b222af
      Duncan Coutts authored
      The HcPkgInfo useSingleFileDb is split into two: supportsDirDbs and
      requiresDirDbs. Then rather than HcPkg.init callers having to do the
      writeFile [] thing, HcPkg.init does it itself automatically based on the
      HcPkgInfo. In the case that supportsDirDbs is True but requiresDirDbs is
      False then we have a choice, to use dir style or file style. For
      compatability reasons, when using ghc/ghc-pkg for the inplace package db
      we want to use the old file style, even though dir style is supported.
      However in other circumstances (e.g. in places in cabal-install) we
      would like to use the dir style if it's supported, and there are no
      backwards compat issues. So HcPkg.init gains a new Bool arg to request
      using the file style if it's still supported. Only this mode is used
      within Cabal itself, but the non-compat mode is available for other
      The compiler-independent initPackageDB is left with the same old
      behaviour, but a new createPackageDB has the extra compat argument
      (which is only passed to hc-pkg for ghc-pkg).
    • Duncan Coutts's avatar
      Change regiserPackage to not require so much info · dee7e0a5
      Duncan Coutts authored
      Drop the now-unused PackageDescription and inplace :: Bool args. And
      instead of taking the whole LocalBuildInfo, just take the bits we need:
      the compiler and program db. The package db stack was already passed in
      separately. Also reorder args to follow standard conventions.
    • Duncan Coutts's avatar
      Don't pass LocalBuildInfo to per-compiler registerPackage functions · b0b57da9
      Duncan Coutts authored
      Rather, pass the individual bits we need, which is the program db
      and in some cases the compiler. This is a step towards having the main
      registerPackage not take the LocalBuildInfo. That is useful in contexts
      like cabal-install where we do not have a full LocalBuildInfo, but we
      still want to be able to register packages in a compiler-agnostic way.
    • Duncan Coutts's avatar
      Move user logging out of registerPackage and into some callers · 27dd76a0
      Duncan Coutts authored
      The main reason is to stop using the pkg and inplace args so that we
      can drop them entirely. A side benefit is that we don't actually want
      to emit a setupMessage for inplace registering, since that's a rather
      uninteresting internal action. We only want it for the explicit
      register command. So only one caller gains a call to setupMessage.
    • Duncan Coutts's avatar
      Change the interface to the per-compiler registerPackage functions · f1ca9680
      Duncan Coutts authored
      Remove the now-unused PackageDescription and inplace :: Bool args.
      Not yet changed the compiler-independent registerPackage.
    • Duncan Coutts's avatar
      UHC: registerPackage stop using source pkg and inplace args · 17af6b98
      Duncan Coutts authored
      UHC's version of registerPackage is the only one that makes use of the
      PackageDescription and inplace :: Bool args, and it's quite wrong for
      doing so. Registering a package should depend on the content of the
      InstalledPackageInfo and the PackageDBStack to register into and the
      Compiler to register with. It should not depend on the original source
      PackageDescription, and should not need a separate inplace arg. The
      location is determined by the PackageDBStack. UHC was not following
      this pattern and thereby forcing the general compiler independent
      registerPackage to take annoying and unnecessary arguments.
      With this patch, the register location is determined by the
      PackageDBStack. The source package id also comes from the
      InstalledPackageInfo rather than the source PackageDescription.
      This patch does not yet change the registerPackage type.