This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 06 Dec, 2016 1 commit
  2. 23 Oct, 2016 2 commits
  3. 20 Oct, 2016 2 commits
    • Mikhail Glushenkov's avatar
      Merge pull request #4011 from christiaanb/dynlibdir-1.24 · a2b9ced8
      Mikhail Glushenkov authored
      Backport "Add `--dynlibdir`" to 1.24
      a2b9ced8
    • Christiaan Baaij's avatar
      Add `--dynlibdir` · 5c901a64
      Christiaan Baaij authored
      --dynlibdir indicates the directory in which dynamic libraries
      are installed. By default this setting is equal to:
      
      $libdir/$abi
      
      The static libraries will still end up in:
      
      $libdir/$libsubdir
      
      With $libsubdir/$abi as the default directory for dynamic
      libraries, dynamic libraries will by default end up in a
      single shared directory (per package database). This has the
      potential to reduce start-up times for dynamically linked
      executable as only one RPATH per package database will be
      needed.
      
      This commit uses the functionality defined in
      
      https://phabricator.haskell.org/D2611
      
      to tell GHC's > 8.0.1 package database that dynamic libraries
      are copied to the directories mentioned in the
      
      `dynamic-library-dirs`
      
      field.
      5c901a64
  4. 19 Oct, 2016 2 commits
  5. 18 Oct, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Workaround GHC #11214 by filtering JavaScriptFFI · 0bae3176
      Herbert Valerio Riedel authored
      Unfortunately, "native" GHC advertises support for `JavaScriptFFI` even though
      it doesn't support it. See also https://ghc.haskell.org/ticket/11214 for respective
      bug.
      
      However, in order to properly declare that packages require `JavaScriptFFI` support
      via `other-extensions` we need to fixup the list of extensions fed to the cabal solver.
      
      This patch does something similiar to the workaround we added some time ago to
      filter out TemplateHaskell for older GHCs which didn't properly advertise
      `TemplateHaskell` availability (c.f. 9f68eb44)
      
      (cherry picked from commit 608517be)
      0bae3176
  6. 16 Oct, 2016 1 commit
  7. 09 Oct, 2016 1 commit
  8. 08 Oct, 2016 12 commits
  9. 02 Oct, 2016 2 commits
  10. 29 Sep, 2016 1 commit
  11. 19 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Store secure repo index data as 01-index.* (#3862) · 9abda456
      Herbert Valerio Riedel authored
      "Secure" cabal repositories use a new extended & incremental
      `01-index.tar`. In order to avoid issues resulting from clobbering
      new/old-style index data, we save them locally to different names.
      
      With this patch, secure repos generate/update the files below on `cabal update`
      
      - `01-index.cache`
      - `01-index.tar`
      - `01-index.tar.gz`
      - `01-index.tar.idx`
      - `mirrors.json`
      - `root.json`
      - `snapshot.json`
      - `timestamp.json`
      
      ...while the legacy codepaths for non-secure repos operate on the files
      
      - `00-index.cache`
      - `00-index.tar`
      - `00-index.tar.gz`
      - `00-index.tar.gz.etag`
      
      This way the old/new codepaths don't interfere with each other anymore.
      
      Note: The format of `01-index.cache` file will be extended by the upcoming `--index-state` feature
      
      This trivially fixes #3854
      (cherry picked from commit dc889b17)
      9abda456
  12. 12 Sep, 2016 1 commit
  13. 11 Sep, 2016 5 commits
    • Mikhail Glushenkov's avatar
      213b0a01
    • Mikhail Glushenkov's avatar
      bootstrap.sh: Bump hackage-security. · cbf3273c
      Mikhail Glushenkov authored
      (cherry picked from commit d64ddcd2)
      cbf3273c
    • Mikhail Glushenkov's avatar
    • Duncan Coutts's avatar
      Add the new hackage root keys for distribution with cabal · 0b8d1428
      Duncan Coutts authored
      To simplify bootstrapping the hackage security, clients like
      cabal-install should ship the root keys. These are the initial root
      keys. Note that there is crypographic evidence that these are the right
      keys that any 3rd part can check.
      
      This patch does not yet enable the security by default, though that is
      easily changed when we're ready. For now one can opt-in by using
      "secure: True" in the ~/.cabal/config file.
      
      (cherry picked from commit 52662105)
      0b8d1428
    • Duncan Coutts's avatar
      Change how config file defaults are applied · baf8d204
      Duncan Coutts authored
      With the user-wide config (ie typically ~/.cabal/config) there's a
      few salient concepts: there's what is actually written in and loaded from
      the config file (lets call it the raw config), there's the config that is
      written to the initial config file the first time cabal is used (lets
      call it the initial config), and then there are various defaults and
      adjustments which are applied to the loaded raw config to produce the
      effective config. Of that, the basic defaults are called the base config.
      
      It is worth noting that the initial config that is written to the
      config file *should not* include the base config or other defaults or
      adjustments. This is important because it means we can change those
      defaults without users having to rewrite their saved config files.
      
      When the commands to check and diff the user config were added the
      distinction between raw and effective config got somewhat confused:
      the userConfigDiff and userConfigUpdate ought to work with the raw
      config -- what is actually written in the file -- not the effective
      config after applying defaults etc. However these commands were using
      loadConfig which returns the effective (not raw) config and then to make
      things work out they had adjust for that by combining the initial config
      with the base config, when really they should just use the loaded raw
      config and the initial config and never use the base config defaults.
      
      We are about to add further adjustments when converting the raw config
      into the effective config to deal with pre-distributing hackage keys. So
      it is important to sort out the raw vs effective config issue first,
      otherwise the userConfigUpdate and userConfigDiff would be telling users
      to write these pre-distributed keys into their config files, when it's
      a lot easier to let these remain as defaults. Similarly, we will soon
      switch the use of secure repositories from opt-in to opt-out and this
      relies on changing the default, which would be ineffective if most users
      config files were updated to fix what the current default is.
      
      So, this patch splits loadRawConfig out of loadConfig and uses it in the
      appropriate places, namely userConfigUpdate and userConfigDiff. Both
      functions are also adjusted to stop using the base config.
      
      The loadConfig now does a loadRawConfig followed by producing the
      effective config by combining with the base config and applying
      additional adjustments. To do this properly, those adjustments are no
      longer applied in the config parser, only but afterwards in loadConfig.
      
      For the same reasons, initialSavedConfig no longer applies the
      addInfoForKnownRepos adjustments since these are defaults and do not
      need to be written to the config file.
      
      As a further minor change, loadRawConfig is changed to not be recursive,
      by making createDefaultConfigFile return the initial config that it
      writes to the file.
      
      (cherry picked from commit 0e6a76e5)
      baf8d204
  14. 08 Sep, 2016 6 commits
  15. 07 Sep, 2016 1 commit
  16. 01 Aug, 2016 1 commit