This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 01 Nov, 2017 1 commit
    • Moritz Angermann's avatar
      Adds sSources and cmmSources. · 4a287659
      Moritz Angermann authored
      # Conflicts:
      #	Cabal/Distribution/PackageDescription/Check.hs
      #	Cabal/Distribution/PackageDescription/Parsec/FieldDescr.hs
      #	Cabal/Distribution/Parsec/Types/FieldDescr.hs
      #	Cabal/doc/developing-packages.rst
      4a287659
  2. 22 Mar, 2017 1 commit
    • Duncan Coutts's avatar
      Simplify HcPkg.register interface · f3c43333
      Duncan Coutts authored
      Remove the variants reregister and registerMultiInstance and generalise
      the main register variant to cover them all. Introduce a RegisterOptions
      record for the variations.
      
      Eliminate an unused form where we supply a file rather than an
      InstalledPackageInfo value.
      
      The motivation is so we can more easily add yet more variations shortly.
      
      This is an API change.
      f3c43333
  3. 17 Mar, 2017 3 commits
    • Edward Z. Yang's avatar
      Refactor MungedPackageId and PackageIndex. · f4ded04f
      Edward Z. Yang authored
      
      
      This makes the necessary changes to 4dc0f30fc36914ee2f01bde016bee98b8e0bb0bb
      to handle component configuring correctly.  It probably is a good step
      towards pkg:lib style dependencies.
      
      The big ideas:
      
      * There's a new AnnotatedId type, which is any identifier (like
        ComponentId), but also with a PackageId and ComponentName.
        It's a bit like ConfiguredId, but ConfiguredId is specialized
        for ComponentId.  There's a conversion function
        annotatedIdToConfiguredId.
      
      * We adopt a totally new strategy for handling MungedPackageId in
        InstalledPackageInfo.  Rather than store the munged package
        identifier in IPI, we NEVER store it, instead computing it
        from the package name and library name (which are stored.)
        There is now code to PARSE a munged package name into these
        two components, so that when we read 'name' we get the
        correct info.  The resulting code is splendidly clear.
      
      * Some places where we took a ComponentName (notably
        computeCompatPackageName) we now take 'Maybe UnqualComponentName'.
        This is more accurate, because compatibility package names are
        only computed for libraries, not other components.  Some code
        in Distribution.Backpack.ReadyComponent is partial now,
        but the invariants should hold up.
      
      * A number of places where MungedId was applied, I undid them.
        Most notable are macro generation (that should be PACKAGES,
        not components) and mkLegacyUnitId (since REALLY old style
        unit identifiers, we won't support internal libraries anyway.)
      
      * Many functions in PackageIndex are monomorphized to
        InstalledPackageInfo.  Fortunately cabal-install's usage
        still works.
      
      * Distribution/Client/SolverPlanIndex.hs, not used by anyone,
        got the axe.
      
      * Dependency solving has a hack to solve the problem of how to
        interpret installed internal libraries in the package database.
        The basic idea is that, although in most cases where we used
        a MungedId, we say it explicitly, in the SOLVER, we munge
        *installed package names* only, and keep the type PackageName.
        It's a hack, but the alternative is to write a lot more code.
        Note that is MORALLY PN is indeed a PackageName, since we really
        are solving for honest to goodness packages, not components!
        See Note [Index conversion with internal libraries] for more
        details.
      
      * ConfiguredId now records the ComponentName.  This is quite important,
        because we need to use it to figure out how we are going to phrase
        --dependency.  In fact, it is a miracle that this worked at all
        (and it only worked because of a very skeevy update to the PackageId
        in the creation of ConfiguredComponent).  Irritatingly, this must
        be a Maybe ComponentName, because a ConfiguredId MIGHT refer to
        a setup component. Very distressing.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      f4ded04f
    • Edward Z. Yang's avatar
      Revert "Revert "Merge pull request #4382 from Ericson2314/munge"" · b0e6c311
      Edward Z. Yang authored
      This reverts commit 4774fb6558974a721176f1fb48d8ce7d43119251.
      b0e6c311
    • Edward Z. Yang's avatar
      Revert "Merge pull request #4382 from Ericson2314/munge" · b1b9d3b1
      Edward Z. Yang authored
      This reverts commit 332d809c, reversing
      changes made to 0c72bc88.
      b1b9d3b1
  4. 09 Mar, 2017 1 commit
  5. 01 Mar, 2017 1 commit
  6. 19 Feb, 2017 2 commits
    • Edward Z. Yang's avatar
      New variant of die which takes verbosity. · 6a652a87
      Edward Z. Yang authored
      
      
      This flips error handling around, so that 'die' now can format
      an error message with call stacks and markers before raising
      it to the top handler.  The top handler detects "verbatim"
      deaths and prints them without formatting.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      6a652a87
    • Edward Z. Yang's avatar
      Refactor setupMessage use in Cabal library. · bc9d5ada
      Edward Z. Yang authored
      
      
      I noticed that I was repeatedly writing the same code
      to print out more elaborate information when we do builds,
      so I refactored it all into one place.  In the process,
      I think that I have made the build output more generally
      useful.
      
      The key changes:
      
          - There is a new function setupMessage' which takes in
            more information than the conventional setupMessage
            does, and prints a more informative message: whereas
            setupMessage will only tell you about the package
            it is being run in, setupMessage' will also tell
            you about the component and instantiation.
      
          - I applied this function to applicable sites, in some
            cases moving around messages to be closer to the place
            where an actual operation takes place.  For example,
            the 'Building' message previously only was triggered
            at the beginning of the build process; now it is
            emitted immediately before we call out to GHC.  This
            is a lot more informative, and avoids people thinking
            that we are slow because of preprocessing (we're not.)
            Something similar happened for Haddock as well.
      
      Before:
      
      Preprocessing library 'spider' for reflex-backpack-0.5.0..
      [1 of 1] Compiling Reflex.Spider.Backpack ( src/Reflex/Spider/Backpack.hs, /srv/code/reflex-backpack/dist-newstyle/build/x86_64-linux/ghc-8.1.20170123/reflex-backpack-0.5.0/c/spider/build/spider/Reflex/Spider/Backpack.o )
      
      After:
      
      Preprocessing library 'host' for reflex-backpack-0.5.0..
      Building library 'host' instantiated with
        Reflex.Host.Sig = reflex-backpack-0.5.0-inplace-spider:Reflex.Spider.Backpack
        Reflex.Sig = reflex-backpack-0.5.0-inplace-spider:Reflex.Spider.Backpack
      for reflex-backpack-0.5.0..
      [1 of 8] Compiling Reflex.Host.Sig[sig] ( host/Reflex/Host/Sig.hsig, /srv/code/reflex-backpack/dist-newstyle/build/x86_64-linux/ghc-8.1.20170123/reflex-backpack-0.5.0/c/host/reflex-backpack-0.5.0-inplace-host+FDoWUmUc0MMBtBRwItgjj9/build/reflex-backpack-0.5.0-inplace-host+FDoWUmUc0MMBtBRwItgjj9/Reflex/Host/Sig.o ) [Reflex.Basics changed]
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      bc9d5ada
  7. 13 Feb, 2017 1 commit
  8. 10 Jan, 2017 1 commit
  9. 18 Dec, 2016 2 commits
  10. 20 Oct, 2016 1 commit
    • Christiaan Baaij's avatar
      Add `--dynlibdir` · d2da6558
      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.
      d2da6558
  11. 18 Oct, 2016 2 commits
  12. 08 Oct, 2016 1 commit
  13. 06 Oct, 2016 5 commits
  14. 02 Oct, 2016 1 commit
  15. 28 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Make `Version` type opaque (#3905) · bb2026c4
      Herbert Valerio Riedel authored
      Similiar to dabd9d98 which made
      `PackageName` opaque, this makes `Distribution.Version.Version` opaque.
      
      The most common version numbers occuring on Hackage are 3- and
      4-part versions. This results in significant Heap overhead due to
      `Data.Version`'s inefficient internal representation.
      
      So like the `PackageName` commit, this commit is a preparatory commit to
      pave the way for replacing `Version`'s internal representation by a
      representation with a memory footprint which can be an order of
      magnitude smaller.
      
      Finally, this also adds a new functor-like convenience function
      
          alterVersion :: ([Int] -> [Int]) -> Version -> Version
      
      for modifying the version number components.
      bb2026c4
  16. 22 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Update default-language & avoid default-extensions (#3880) · f87738df
      Herbert Valerio Riedel authored
      This upgrades the `default-language: Haskell98` to `Haskell2010`
      and removes `default-extensions: RankNTypes, FlexibleContexts`
      in favor of adding `LANGUAGE` pragmas where needed.
      
      Moroever, this also drops `LANGUAGE` pragmas which have become redundant
      due to `Haskell2010` (specifically, `EmptyDataDecls`,
      `ForeignFunctionInterface` and `PatternGuards`)
      
      Finally, an `other-extensions` specification is put in place for the
      `Cabal` library component.
      
      This helps loading up files directly in GHCi, such as e.g. `ghci Setup.hs`
      without having to specify `-X...` flags.
      f87738df
  17. 11 Sep, 2016 1 commit
  18. 09 Sep, 2016 1 commit
  19. 08 Sep, 2016 1 commit
    • Edward Z. Yang's avatar
      Provide useful call-stacks over all IO code. · 48a0d6ce
      Edward Z. Yang authored
      
      
      The key idea is that we define:
      
          type IO a = HasCallStack => Prelude.IO a
      
      and voila, call stacks are maintained across all IO!  You can
      look at the stacks using -v"debug +callstack".
      
      There are a number of IO functions for which the call stack is
      never used.  They are explicitly annotated using NoCallStackIO.
      Maybe some day they will use call stacks and we can change their
      types.  Similarly, there are a number of functions which do
      have type IO, but then suppress the redundant constraint error
      using "_ = callStack". Maybe some day we will attach call
      stacks to the exceptions we throw.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      48a0d6ce
  20. 06 Sep, 2016 2 commits
  21. 21 Aug, 2016 1 commit
    • Edward Z. Yang's avatar
      One-component configure, fixes #2802. · a090a494
      Edward Z. Yang authored
      Described in: https://github.com/ghc-proposals/ghc-proposals/pull/4
      
      
      
      ./Setup configure now takes an argument to specify a specific
      component name that should solely be configured.
      
      Most of the gyrations in Configure are all about making it so that
      we can feed in internal dependencies via --dependency.
      
      I dropped the package name match sanity check to handle convenience
      library package name munging.  Consider an internal library named
      'q' in package 'p'.  When we install it to the package database,
      we munged the package name into 'z-p-z-q', so that it doesn't
      conflict with the actual package named 'q'.  Now consider when
      we feed it in with --dependency q=p-0.1-hash-q.  Previously,
      Cabal checked that the 'q' in --dependency matched the package
      name in the database... which it doesn't. So I dropped the check.
      
      I also had to make register/copy unconditionally install internal
      libraries; otherwise you can't refer to them from later builds.
      
      Also a miscellaneous refactor: convenience libraries are printed with a
      "header" stanza now (not really a stanza header).
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      a090a494
  22. 07 Aug, 2016 1 commit
  23. 26 Jul, 2016 2 commits
  24. 24 Jul, 2016 1 commit
    • Edward Z. Yang's avatar
      As much as possible, expunge uses of localPkgDescr. · e3c64e6d
      Edward Z. Yang authored
      
      
      The big change here is that most of the functions in
      Distribution.Types.HookedBuildInfo have to take a
      PackageDescription explicitly.  I hate the new type,
      so I primed these new functions, and added functions
      which use 'localPkgDescr'.  Presently those have WARNINGs
      attached to them so people don't accidentally use them;
      once we fix 'HookedBuildInfo' we can change this.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      e3c64e6d
  25. 23 Jul, 2016 1 commit
    • Edward Z. Yang's avatar
      Refactor LocalBuildInfo interface. · d94ddc0e
      Edward Z. Yang authored
      
      
      This is an omnibus patch, with the overall goal of making
      LocalBuildInfo Great Again.  The essential ideas:
      
      * New type 'TargetInfo' which bundles together 'ComponentLocalBuildInfo'
        and 'Component'.  Eventually, it will also record file paths / module
        targets.  This data structure is basically what you want; a lot of
        old Cabal code did lots of gyrations converting from
        'ComponentLocalBuildInfo' to 'Component' and vice versa, now
        it's all centralized.
      
      * The "new" API for 'LocalBuildInfo' is in
        "Distribution.Types.LocalBuildInfo".  The general principle
        is, where we previous dealt in 'ComponentLocalBuildInfo',
        we now deal in 'TargetInfo'.  There are shockingly few
        functions we need!
      
      * I've restored 'componentsConfigs' to its Cabal 1.24 signature
        for BC.
      
      * I killed a number of unused functions from "Distribution.Simple.LocalBuildInfo":
        'getLocalComponent', 'maybeGetDefaultLibraryLocalBuildInfo',
        'maybeGetComponentLocalBuildInfo', 'checkComponentsCyclic' and
        'enabledComponents'.  For each I checked on Hackage that they were
        not used.
      
      * 'getComponentLocalBuildInfo', 'withComponentsInBuildOrder' and
        'componentsInBuildOrder' are deprecated to encourage people
        to instead use the 'TargetInfo's to finger which components
        they want built.
      
      * 'ComponentLocalBuildInfo' now stores internally the computed
        'componentInternalDeps', so that 'LocalBuildInfo' can simply store
        a graph of 'ComponentLocalBuildInfo'.
      
      * The code in Configure has been streamlined to use our new Graph
        data type to great success.
      
      * The type of 'runTest' changed to take a 'ComponentLocalBuildInfo',
        bringing it more in line with everything else.
      
      * New function 'readTargetInfos' which combines 'readBuildTargets'
        and 'checkBuildTargets', which is what you really wanted anyway.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      d94ddc0e
  26. 21 Jul, 2016 1 commit
  27. 12 Apr, 2016 2 commits
  28. 08 Apr, 2016 1 commit