This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 30 Dec, 2015 2 commits
    • randen's avatar
      Add foldl' import · 6a62d2d2
      randen authored
      -- building cabal-install in a sandbox with add-source
      on Cabal, still builds the cabal executable even though
      the Cabal build failed :-(
      6a62d2d2
    • randen's avatar
      The Cabal part for fully gcc-like response files · 0384727a
      randen authored
      * Cabal/Distribution/Simple/Haddock.hs
        * VERY IMPORTANT! this feature depends on a particular
          version of haddock, that includes the corresponding
          support for these style of response files.  However,
          we do not really know that version number!  So, this
          change here must be co-ordinated with the haddock project.
      0384727a
  2. 17 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Define semigroup instances · f6428740
      Herbert Valerio Riedel authored
      This makes the code `-Wcompat`-clean with GHC 8.0
      
      Due to the amount of `Monoid` instances, a compat-layer is used
      rather than flooding the code-base with CPP conditionals.
      f6428740
  3. 26 Oct, 2015 1 commit
  4. 13 Oct, 2015 1 commit
  5. 09 Oct, 2015 1 commit
    • Edward Z. Yang's avatar
      Implement ComponentId, replacing PackageKey and InstalledPackageId. · b083151f
      Edward Z. Yang authored
      
      
      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: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      b083151f
  6. 04 Oct, 2015 1 commit
    • Benno Fünfstück's avatar
      cabal haddock: add --for-hackage flag · 0ecb2835
      Benno Fünfstück authored
      This is the first step to implement #2080. It adds a new flag
      to `cabal haddock`, called `--for-hackage`, which will generate
      documentation suitable for upload to hackage. It's only a collection
      of flags, and matches the flags used by the hackage doc builder.
      0ecb2835
  7. 17 Aug, 2015 1 commit
  8. 16 Aug, 2015 1 commit
  9. 30 Jul, 2015 1 commit
    • randen's avatar
      Propose code for supporting haddock response files · e61d8dd2
      randen authored
      This change is for adding the ehancement to support haddock
      response files.  This is what was used to build HP 7.10.2
      for Windows, but it does need a corresponding change in
      haddock to utilize it. Hopefully, this and its corresponding
      haddock change can make it into the next ghc release and
      eliminate much gnashing of teeth, error prone, and time
      consuming manual steps in the HP build process.
      
      Modified:
      
      * Cabal/Distribution/Simple/Haddock.hs
        * renderArgs function: I put a couple of things into locals
          since I needed another use for UTF8 support check, plus I
          added another check based on version; the temp file logic
          was just as the prologue case above but I did need to
          repeat the invocation of the 'k' function in order to
          keep the cases separate and allow proper handling of the
          temp file automatic (or not, per --keep-temp-files)
          deletion.  Important: the haddock version being check
          against for response file support, greater than 2.16.1,
          is a placeholder and may or may not be the actual value
          since that will depend on the as-yet-unreleased haddock
          (which looks like it may be >2.16.1 but at this moment is
          not released).
      e61d8dd2
  10. 21 Jul, 2015 1 commit
    • Edward Z. Yang's avatar
      Refactor Cabal around the idea of "library names". · f47732a5
      Edward Z. Yang authored
      
      
      In GHC 7.10, Cabal always generate package keys, including in
      cases where Backpack was involved (e.g. --instantiated-with).
      In fact, in these case, GHC needs to be able to generate the
      package key (because it will often make a substitution on the
      instantiation, and needs to know if this identity coincides with
      anything else we've seen previously).
      
      Thus, we introduce a new notion, the 'LibraryName', which
      is JUST the non-Backpack portion of a package key.  For ordinary
      packages that are definite, a 'LibraryName' is simply
      the 'PackageId' plus 'PackageKey'; for indefinite Backpack packages,
      when a package gets instantiatied, it may end up with different
      'PackageKey's even though the 'LibraryName' stays the same.
      'LibraryName's can be computed purely by Cabal.
      
      This patch:
      
          - Defines library name, which are the source package ID plus
            a hash of all the source package ID and the library names of external,
            textual dependencies,
      
          - Redefines the package key to be JUST the hash portion of a
            library name, in the case that Backpack is not used,
      
          - Records the library name in InstalledPackageInfo.
      
      Note: the source package ID is included both externally (so the library
      name is a useful handle to refer to package) and internally (so the
      hash can stand alone as the package key.)
      
      A major refactoring which is part of this commit is moving package keys/library
      names from LocalBuildInfo to LibComponentBuildInfo.  If you have an LBI, you can
      still extract a package key/library name using the new
      localPackageKey/localLibraryName function (which looks through the
      ComponentBuildInfos of a LocalBuildInfo for the library in question).  This is
      conceptually cleaner for two reasons:
      
          1. Only dependencies of the *library* are counted as part
          of the library name, as opposed to *all* dependencies which
          we previously used.
      
          2. A library name doesn't really mean much for an executable,
          or a test suite, since no one else will have to link against
          them.  So we can fall back on something simpler.
      
      A more minor refactoring is the 'LibraryName' type, which was
      previously defined by LocalBuildInfo and generally looked something
      like "HSprocess-0.1-XXXX".  We change the meaning of 'LibraryName'
      to be "process-0.1-XXXX" (thus we have to insert some HS additions
      in the code) and eliminate componentLibraries, thus assuming that
      there is only ONE Haskell library (which was the case.)  So
      we remove a little bit of generality and in return get code
      that is much easier to read.  (The only downside is GHC's hack
      to split DLLs into multiples has to be adjusted slightly, but
      this is not a big price to pay.)
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      f47732a5
  11. 31 Mar, 2015 1 commit
  12. 13 Mar, 2015 1 commit
    • Edsko de Vries's avatar
      Make sure to pass the package key to ghc · 3e78870d
      Edsko de Vries authored
      In https://github.com/haskell/cabal/pull/2439 the invocation of Haddock is
      changed to use Haddock's new `--package-name` and `--package-version` flags,
      necessary for GHC >= 7.10 (Cabal issue
      https://github.com/haskell/cabal/issues/2297 / Haddock issue
      https://github.com/haskell/haddock/issues/353). However, this commit also
      removes the `-package-name` argument to GHC. This is incorrect, as it means
      that GHC will end up calling the package `main` and we end up with Haddock link
      environments such as
      
          (trans_H9c1w14lEUN3zdWCTsn8jG:Control.Monad.Trans.Error.strMsg, main:Control.Monad.Error.Class)
      
      Note that before this commit we ended up with
      
          (trans_H9c1w14lEUN3zdWCTsn8jG:Control.Monad.Trans.Error.strMsg, mtl-2.1.1:Control.Monad.Error.Class)
      
      which is equally wrong as it uses a package source ID rather than a package key
      (Haddock issue https://github.com/haskell/haddock/issues/362). Instead, we need
      to pass _both_ `--package-name` and `--package-version` to Haddock, and
      `-package-name` or `-this-package-key` to GHC, depending on the version.
      Thankfully the infrastructure for chosing between `-package-name` and
      `-this-package-key` is already in place, so we just have to make sure to
      populate the `ghcPackageKey` field. After this commit the link environment
      looks like
      
          (trans_H9c1w14lEUN3zdWCTsn8jG:Control.Monad.Trans.Error.strMsg, mtl_Koly6qxRZLf86guywd4tkE:Control.Monad.Error.Class)
      
      which is correct.
      3e78870d
  13. 25 Feb, 2015 1 commit
  14. 18 Dec, 2014 1 commit
  15. 10 Dec, 2014 2 commits
    • Luite Stegeman's avatar
      use CompilerInfo rather than CompilerId for resolving flags and · 7d91b773
      Luite Stegeman authored
      path templates.
      
      CompilerInfo contains more information about the compiler than
      CompilerId, which just stores the flavour and version. In particular,
      CompilerInfo knows an AbiTag, which can be used to tell binary
      incompatible results from the same compiler apart, and detailed
      information about supported languages and extensions.
      
      Some fields in CompilerInfo may be left unknown (Nothing). This can
      be used in the future to allow partially resolving configurations
      based on supported languages or extensions.
      7d91b773
    • Luite Stegeman's avatar
      Add the js-sources and various ghcjs-options fields to PackageDescription · 81330d03
      Luite Stegeman authored
      This patch adds the js-sources field, for JavaScript source code
      that should be included in compiled programs, similar to c-sources
      for other targets.
      
      It also adds ghcjs-options, ghcjs-shared-options and ghcjs-prof-options
      and makes the underlying code for options easier to extend.
      81330d03
  16. 21 Oct, 2014 2 commits
  17. 19 Oct, 2014 1 commit
  18. 15 Aug, 2014 1 commit
  19. 04 Aug, 2014 1 commit
  20. 10 May, 2014 4 commits
    • Iain Nicol's avatar
      Fix: "cabal haddock" uses CPP overzealously · ba4ae3d0
      Iain Nicol authored
      Until recently we supported ancient versions of Haddock, pre v2.0.  To
      support the CPP extension with such versions, cabal had to invoke the
      CPP before invoking Haddock on the output.  For simplicity cabal would
      invoke the CPP on all Haskell files, if any Haskell file required CPP.
      However, invoking CPP on a file which does not require it can cause
      build failures.
      
      Haddock v2.0+ supports the CPP via GHC, and even automatically
      preprocesses any file with the {-# LANGUAGE CPP #-} pragma. Hence we
      simply need only tell Haddock to enable the CPP when the CPP is a
      package level default extension.
      
      Fixes issue #1808.
      ba4ae3d0
    • Iain Nicol's avatar
      Use Haddock's builtin support for .lhs and CPP · 5729bc5c
      Iain Nicol authored
      This is a code simplification on our end.
      
      Thanks to Mikhail Glushenkov for the suggestion.
      5729bc5c
    • Iain Nicol's avatar
      Remove support for Haddock versions < 2.0 · 98c537f1
      Iain Nicol authored
      Dropping this support is unlikely to be a problem in practice.  Debian
      oldstable is currently on version 2.6.0 of Haddock, for example.
      
      This change enables future code simplification.  Currently we
      preprocess both Haskell files requiring the CPP and Literate Haskell
      files; newer versions of Haddock can handle these natively.
      
      Fixes issue #1718.
      98c537f1
    • Iain Nicol's avatar
      a718eb07
  21. 14 Apr, 2014 1 commit
  22. 21 Mar, 2014 1 commit
  23. 10 Mar, 2014 2 commits
  24. 09 Mar, 2014 1 commit
  25. 02 Feb, 2014 4 commits
  26. 02 Dec, 2013 1 commit
    • Duncan Coutts's avatar
      Fix the haddock --html-location= for relative URLs · 32dddcb1
      Duncan Coutts authored
      The previous fix in isue #1407 turned out to be in the wrong place and
      so applied to both the haddock-html from the ghc-pkg output, and also to
      the location passed via the --html-location flag. For the
      --html-location flag it is important that we can use relative URLs like
      /package/$pkg-$version/docs because that is what we need for hackage.
      Note that that is a relative URL, it's relative to the server root.
      However that was being interpreted as a local file path and being given
      the file:// prefix. So now we move the file:// URL stuff to the right
      place so it only applies to the location given in the haddock-html field
      of the package registration.
      32dddcb1
  27. 31 Oct, 2013 1 commit
  28. 16 Oct, 2013 1 commit
  29. 02 Sep, 2013 1 commit
  30. 21 Aug, 2013 1 commit