This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 12 Oct, 2016 1 commit
    • Bartosz Nitka's avatar
      Dedupe include dirs inherited from dependencies · 6e31b30d
      Bartosz Nitka authored
      If you build a big number of packages, all with
      the same extra -I flags, the flags get inherited
      by the dependent packages and duplicated.
      For big dependency trees it can exceed the
      maximum command line length on some systems,
      this happened to me with Linux and hoogle 5.
      
      This patch decreases the redundancy by
      dropping all but the first occurrence of
      an include dir, preserving the semantics,
      as they are processed left to right.
      6e31b30d
  2. 08 Oct, 2016 2 commits
  3. 06 Oct, 2016 5 commits
    • Edward Z. Yang's avatar
      Use the new Backpack code for the configure step · 688b31e3
      Edward Z. Yang authored
      Many of the configure functions were factored out and moved to the new
      Backpack modules. The new configure action makes a call to
      Distribution.Backpack.Configure to setup the ComponentLocalBuildInfo.
      
      Also add an @--instantiate-with@ flag to ./Setup configure, so that
      cabal-install can specify how it wants to instantiate a package that
      it is building.
      
      Also do the minimal necessary adjustments in cabal-install.
      688b31e3
    • Edward Z. Yang's avatar
      Extend ComponentLocalBuildInfo with backpack info · be1a184c
      Edward Z. Yang authored
      (1) add 'componentInstantiatedWith' to record how a component was
      instantiated (analogous to @instantiated-with@) and
      (2) fix 'componentComponentId' for the new constructors in 'Module'.
      be1a184c
    • Edward Z. Yang's avatar
      Replace the module renaming/thinning system · 1017f710
      Edward Z. Yang authored
      We had an old implementation of 'ModuleRenaming', with the
      assumption that it would be used directly in build-depends; since
      we have dropped this assumption, we can refactor 'ModuleRenaming'
      and we do so.  The main idea is to make the data type more directly
      reflect the syntax you can specify in a Cabal file; so the default
      renaming and an explicit thinning renaming are now different
      constructors.  It's no longer possible to use the "with" syntax, but
      it's not necessary either, since we have a special backpack-includes
      field to specify renamings, so we don't need them to be Monoidal.
      
      There is also a new syntax for 'hiding', which just lets you hide
      some modules when including a package. Handy!
      
      Previously, we recorded 'ModuleRenaming' in @build-depends@, but
      separated it out when we stored in 'BuildInfo'.  We now go even
      further, by changing it from a 'Map' (the only thing @build-depends@
      could support) to a list (so that a package name can be specified
      multiple times.)  This is good because now a user can instantiate
      something several times, which is useful in Backpack.
      
      Also add the new field @backpack-includes@ which can be used to exert
      fine-grained control over what modules a package brings into scope,
      include it multiple times, etc.
      
      In the .cabal checks, replace 'depsUsingThinningRenamingSyntax' with a
      more direct check to see if @backpack-includes@ was used.
      
      Dropped the legacy 'lookupRenaming' export from ModuleRenaming and
      PackageDescription; we will shortly not use it anymore. As an
      intermediate hack we have a local definition in Configure, but this
      will go away shortly.
      1017f710
    • Edward Z. Yang's avatar
      Backpack InstalledPackageInfo representation changes · 3de0e4c4
      Edward Z. Yang authored
      New field, @instantiated-with@, which records the full
      module substitution (it is dropped when we do 'improveUnitId').
      
      For flexibility in the case of indefinite packages, some
      occurences of Module are relaxed to IndefModule (exposedReexport).
      This is just for convenience; in the case of a definite package
      these reexports and instantiations are guaranteed to be 'Module's.
      
      This patch also includes the minimal changes in other modules
      needed due to the representation change.
      3de0e4c4
    • Edward Z. Yang's avatar
      Introduce the new representation of UnitId · d7bd9078
      Edward Z. Yang authored
      'SimpleUnitId' constructor renamed to 'UnitId', and augmented
      with a new field 'Maybe String' recording a hash that uniquely
      identifies an instantiated unit of the library 'ComponentId'.
      'UnitId' can't be used to represent partially instantiated
      unit identifiers; see Distribution.Backpack for how we handle that.
      
      Previous uses of 'SimpleUnitId' should now use 'newSimpleUnitId'.
      'unitIdComponentId' folded into a record selector for 'ComponentId'.
      d7bd9078
  4. 30 Sep, 2016 1 commit
  5. 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
  6. 27 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Make `PackageName` type opaque (#3896) · dabd9d98
      Herbert Valerio Riedel authored
      When looking at heap-profiles of `cabal-install`, the `(:)` constructor
      stands out as the most-allocated constructor on the heap.
      
      Having to handle 10k+ package names contributes to the allocation
      numbers, especially on 64bit archs where ASCII `String`s have a 24 byte
      per character footprint.
      
      This commit is a preparatory commit to pave the way for changing
      `PackageName`'s internal representation to something like
      `ShortByteString` (which is essentially a thin wrapper around primitive
      `ByteArray#`s which themselves have have an overhead of 2 words + one
      byte per ASCII character rounded up to nearest word) which would allow
      to reduce the memory footprint by a full order of magnitude, as well as
      reduce pointer chasing and GC overhead.
      dabd9d98
  7. 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
  8. 19 Sep, 2016 2 commits
    • Edward Z. Yang's avatar
      Never use --enable-profiling when invoking Setup. · bf3d3e68
      Edward Z. Yang authored
      
      
      In Cabal 1.22.5.0, the semantics of
      --disable-profiling/--enable-profiling depend on ordering (because there
      is a hack that operates by looking at the current flag assignment and
      doing something). In particular, if I specify --enable-library-profiling
      --disable-profiling, I end up with library profiling DISABLED.
      
      The fix is that we NEVER pass --enable-profiling or --disable-profiling
      to Cabal. At the moment, and according to my historical analysis, Cabal
      ONLY uses configProf to affect the effective library/executable
      profiling, which means that anything we do with --enable-profiling, we
      can do using the library/executable profiling individually. Since these
      are always flags for the versions of Cabal library we support, we will
      get order invariance. Historical versions have varied on whether or not
      setting executable profiling implies library profiling, but if we set
      both explicitly this change in behavior doesn't matter.
      
      This patch is difficult to test because the bad profiling flags
      can't be induced on an inplace build.  I tested by hand by building
      a package that depended on 'distributive' by hand.
      
      Fixes #3790.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      bf3d3e68
    • Edward Z. Yang's avatar
  9. 18 Sep, 2016 2 commits
    • Edward Z. Yang's avatar
      Use enabledBuildInfos rather than allBuildInfo. · b17a45e9
      Edward Z. Yang authored
      
      
      In many places, we incorrectly used allBuildInfo, which
      returns all BuildInfos that are buildable, and not
      necessarily the ones we are actually going to *build*.
      This used to "mostly do the right thing" because we
      literally edited the PackageDescription to nub out things,
      so you wouldn't see non-enabled components anyway.  However
      when I added support for per-component configure, I stopped
      editing the PackageDescription, which meant all of these
      uses were wrong.
      
      So, I updated them to do the right thing. Note that there
      are still uses of allBuildInfo in Check, but that probably
      requires a closer look.
      
      Fixes #3847.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      b17a45e9
    • Edward Z. Yang's avatar
      Refactor ComponentEnabledSpec into ComponentRequestedSpec. · d03fe594
      Edward Z. Yang authored
      
      
      In the previous documentation for 'ComponentEnabledSpec', I claimed
      that enabled components were buildable, as well as requested
      by the user.  In the course of working on #3847, however,
      I realized that I hadn't actually *checked* that the component
      was buildable anywhere.  In particular, the 'ComponentDisabled'
      reason was *never used*.  This mostly didn't cause problems,
      however, because when we 'flattenPD' all non-buildable components
      get deleted, so you basically never actually have a non-buildable
      'Component'.
      
      But it still seemed a bit silly, so I fixed it by doing this:
      
      1) I introduce a new concept of a component being requested,
      which captures the use of --enable-tests and friends.  This
      does NOT imply buildability.  Renamed ComponentEnabledSpec
      to ComponentRequestedSpec
      
      2) A component is enabled if it is requested and buildable.
      If you give me a Component and a ComponentRequestedSpec I
      can tell you if it's enabled.  However, if you give me a
      ComponentName I can't, because I have no idea if it's buildable.
      
      3) Stopped reexporting ComponentRequestedSpec from
      Distribution.Simple.LocalBuildInfo
      
      4) Added a test for attempting to specify a non-buildable
      component as a target.  The test is accepting suboptimal
      output at the moment, see #3858.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      d03fe594
  10. 11 Sep, 2016 1 commit
  11. 09 Sep, 2016 1 commit
  12. 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
  13. 06 Sep, 2016 8 commits
  14. 21 Aug, 2016 5 commits
    • Edward Z. Yang's avatar
      Solve for, build, and add to path build-tools dependencies. · c0a48602
      Edward Z. Yang authored
      
      
      This fixes #220: new-build now builds, installs and adds executables to
      PATH automatically if they show up in 'build-tools'.  However, there is
      still more that could be done: the new behavior only applies to a
      specific list of 'build-tools' (alex, happy, etc) which Cabal recognizes
      out of the box.  The plan is to introduce a new 'tool-depends' field to
      allow dependencies on other executables as well.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      c0a48602
    • Edward Z. Yang's avatar
      Be more careful about ComponentId versus UnitId. · bd7e2310
      Edward Z. Yang authored
      
      
      Two big ideas:
      
          * @--dependency@ takes a ComponentId, not UnitId.
            I used to think it should be a UnitId but it is
            now clear that you want to finger the indefinite
            unit id, which can be uniquely identified with
            a ComponentId
      
          * When hashing for an InstalledPackageId in
            new-build, we should produce a ComponentId,
            not a UnitId.
      
      While cleaning up the results, for any codepaths which we don't plan on
      implementing Backpack (Distribution.Client.Install, I'm looking at you),
      just coerce ComponentId into UnitIds as necessary.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      bd7e2310
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Per-component new-build support (no Custom support yet). · d9bf6788
      Edward Z. Yang authored
      
      
      A bit of a megapatch.  Here's what's in it:
      
      * First, a few miscellaneous utility functions and reexports
        in Cabal.  I could have split these into a separate commit
        but I was too lazy to.
      
      * Distribution.Client.Install got refactored:
        instead of using PackageFixedDeps, it uses IsUnit
        instead.  This is because we weren't using ComponentDeps
        in a nontrivial way; we just need some graph structure
        and IsNode (with UnitId keys) fulfills that. I also removed the
        invariant checking and error reporting because it was
        being annoying (we check the invariants already in
        SolverInstallPlan).
      
      * Look at Distribution.Client.ProjectPlanning.Types.
        This contains the primary type change: ElaboratedConfiguredPackage
        is now EITHER a monolithic ElaboratedPackage, or a per-component
        ElaboratedComponent (it should get renamed but I didn't do that
        in this patch.)  These are what we're going to store in our
        plans: if a package we're building has a Setup script which supports
        per-component builds, we'll explode it into a component.  Otherwise
        we'll keep it as a package.  We'll see codepaths for both
        throughout.
      
      * OK, so the expansion happens in ProjectPlanning, mostly in
        'elaborateAndExpandSolverPackage'.  You should review the
        package hash computation code closely.  When we can separate
        components, we compute a hash for each INDEPENDENTLY.  This
        is good: we get more sharing.
      
      * We need to adjust the target resolution and pruning code
        in ProjectOrchestration and ProjectPlanning.  I did a dumb
        but easy idea: if a user mentions 'packagename' in a
        target name, I spray the PackageTarget on every
        possibly relevant IPID in buildTargets', and then pare
        it down later.
      
      * And of course there's code in ProjectBuilding to actual
        do a configure and then build.
      
      * We change the layout of build directories so that we can
        track each component separately.  While I was doing that,
        I also added compiler and platform information.
      
      Custom doesn't work yet because I need to give them their own
      separate component, and teach Cabal how to build them specially.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      d9bf6788
    • 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
  15. 26 Jul, 2016 2 commits
  16. 25 Jul, 2016 2 commits
  17. 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
  18. 23 Jul, 2016 2 commits
    • 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
    • Herbert Valerio Riedel's avatar
      Implement `--allow-older` (dual to `--allow-newer`) (#3466) · 5944c3e9
      Herbert Valerio Riedel authored
      This implements the flag `--allow-older` which is the analogous to
      `--allow-newer` acting on lower bounds.
      5944c3e9
  19. 22 Jul, 2016 1 commit