This project is mirrored from Pull mirroring updated .
  1. 05 Sep, 2016 2 commits
    • Max Amanshauser's avatar
      docs: move new docs into place [skip ci] · 02cc8f5c
      Max Amanshauser authored
    • novadenizen's avatar
      Added TODO: eradicateNoParse comments to all uses of bare 'read' · 978ca74e
      novadenizen authored
      When 'read' is used on invalid input, it raises a "no parse" exception that is
      typically very unhelpful to the user.  It is generally more desirable to either
      handle the error or produce a more helpful error message.
      This actually happens sometimes.  When a user creates a detailed-0.9 test
      suite, and that test suite crashes or is killed so it can't write its result
      log, the bare read in Distribution.Simple.Test.LibV09.runTest fails and cabal
      fails with "no parse".
      I could have just written a patch to fix that, but it seemed like a better idea
      to find all uses of bare read and see what we can do for all of them.
      I have grepped through the repository and I think I've found all uses of bare
      'read' that might raise the dreaded 'no parse' exception.  The plan is to
      separately patch each of them by either replacing with an alternate Read
      function (readMaybe is the most obvious candidate), proving the read will
      always succeed, or establishing that producing a 'no parse' exception is the
      most desirable behavior.
  2. 04 Sep, 2016 6 commits
  3. 03 Sep, 2016 3 commits
  4. 02 Sep, 2016 3 commits
  5. 01 Sep, 2016 5 commits
  6. 30 Aug, 2016 1 commit
  7. 29 Aug, 2016 1 commit
  8. 28 Aug, 2016 1 commit
  9. 23 Aug, 2016 1 commit
  10. 21 Aug, 2016 9 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 <>
    • Edward Z. Yang's avatar
    • 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 <>
    • Edward Z. Yang's avatar
    • 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
      * 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
      * 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 <>
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      One-component configure, fixes #2802. · a090a494
      Edward Z. Yang authored
      Described in:
      ./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 <>
    • Edward Z. Yang's avatar
  11. 20 Aug, 2016 1 commit
  12. 18 Aug, 2016 1 commit
  13. 17 Aug, 2016 2 commits
  14. 16 Aug, 2016 1 commit
  15. 13 Aug, 2016 1 commit
  16. 11 Aug, 2016 2 commits
    • fmaste's avatar
      Add new 'autogen-modules' field · c0108673
      fmaste authored
      Modules that are built automatically at setup, like Paths_PACKAGENAME or others created with a build-type custom, appear on 'other-modules' for the Library, Executable, Test-Suite or Benchmark stanzas or also on 'exposed-modules' for libraries but are not really on the package when distributed. This makes commands like sdist fail because the file is not found, so with this new field modules that appear there are treated the same way as Paths_PACKAGENAME was and there is no need to create complex build hooks.
      Just add the module names on 'other-modules' and 'exposed-modules' as always and on the new 'autogen-modules' besides.
    • Edward Z. Yang's avatar