This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 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
  2. 18 Sep, 2016 1 commit
    • 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
  3. 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
  4. 26 Jul, 2016 1 commit
  5. 22 Jul, 2016 1 commit
  6. 21 Jul, 2016 2 commits
  7. 19 Apr, 2016 1 commit
  8. 29 Mar, 2016 1 commit
    • Edward Z. Yang's avatar
      Implement "convenience libraries", fixes #269. · 2040c1c9
      Edward Z. Yang authored
      
      
      Convenience libraries are package-private libraries
      that can be used as part of executables, libraries, etc
      without being exposed to the external world.  Private
      libraries are signified using the
      
          library foo
      
      stanza.  Within a Cabal package, the name convenience library
      shadows the conventional meaning of package name in
      build-depends, so that references to "foo" do not indicate
      foo in Hackage, but the convenience library defined in the
      same package. (So, don't shadow Hackage packages!)
      
      This commit implements convenience libraries such that they
      ARE installed the package database (this prevents us from
      having to special case dynamically linked executables);
      in GHC 7.10 and later they are installed under the same
      package name as the package that contained them, but have
      a distinct "component ID" (one pay off of making the distinction
      between component IDs and installed package IDs.)
      
      There is a "default" library which is identified by the fact
      that its library name coincides with the package name.  There
      are some new convenience functions to permit referencing this.
      
      There are a few latent bugs in this commit which are fixed
      in later commits in this patchset.  (Those bugfixes required
      a bit of refactoring, so it's clearer if they're not
      with this patch.)
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      2040c1c9
  9. 18 Feb, 2016 1 commit
  10. 30 Jan, 2016 1 commit
  11. 29 Jan, 2016 1 commit
  12. 27 Jan, 2016 1 commit
    • kristenk's avatar
      Improve algorithm for choosing flags with './Setup configure' · 6d42e6ed
      kristenk authored
      Cabal previously tried all flag combinations, which was very slow.  The new
      algorithm assigns one flag at a time, and backtracks when a flag introduces a
      dependency that is unavailable.
      
      The new algorithm handles the Buildable field by adding an extra conditional at
      the top level of each component that represents the condition for which the
      component is buildable.  Since all dependencies go under the "then" branch, they
      are only required when a flag choice makes the component buildable.  The buildable
      logic is taken from the cabal-install dependency solver.
      
      This commit also changes the error message that is shown when dependencies are
      missing.  Previously, Cabal printed the shortest list of missing dependencies
      from a single flag assignment.  Now it takes the union of all dependencies that
      caused it to backtrack when trying different combinations of flags, which
      requires less searching.
      6d42e6ed
  13. 26 Jan, 2016 1 commit
  14. 25 Jan, 2016 1 commit
  15. 14 Jan, 2016 1 commit
    • Andres Löh's avatar
      Do not consider dependencies of non-buildable components. · 53d85bb0
      Andres Löh authored
      When configuring a package, the condition trees in the package
      descriptions are evaluated according to the known configuration
      and flag assignment.
      
      During this process, it becomes also known whether a component
      has its "Buildable" flag set to True or False. We now disregard
      all dependencies of non-buildable components.
      53d85bb0
  16. 08 Jan, 2016 1 commit
    • Edward Z. Yang's avatar
      Remove same-package import lists, fixes #2835. · 639cd007
      Edward Z. Yang authored
      
      
      Instead of qualifying, in some cases I just added an extra
      'hiding' pragma to squelch errors.  Common conflicts
      (just grep for hiding):
      
          - Flag
              - Distribution.Simple.Compiler
              - Distribution.PackageDescription
              - Distribution.Simple.Setup
          - installedComponentId
              - Distribution.Package
              - Distribution.InstalledPackageInfo
          - doesFileExist
              - Distribution.PackageDescription.Check
          - instantiatedWith
              - I renamed the field in InstalledPackageInfo.  But
                it's probably going away with Backpack bits; I
                migth just excise it soon.
          - absoluteInstallDirs and substPathTemplate
              - Distribution.Simple.InstallDirs
              - Distribution.Simple.LocalBuildInfo
      
      I fixed some shadowing errors by renaming local variables in some cases.
      Common shadowings (we should perhaps consider not using these as
      method/field names):
      
          - freeVars
          - components
          - noVersion
          - verbosity
          - get
          - description
          - name
      
      Some data structures were moved around (IPIConvert and ABIHash)
      to make it easier to handle import lists.
      
      Some functions in Utils could be turned into reexports of standard
      library functions.
      
      No explicit imports were removed from non-Cabal imports.  These
      imports help maintain warning cleanliness across versions of GHC,
      so I don't recommend removing them.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      639cd007
  17. 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
  18. 01 Nov, 2015 1 commit
  19. 27 Oct, 2015 1 commit
  20. 06 Mar, 2015 1 commit
  21. 10 Dec, 2014 1 commit
    • 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
  22. 14 Apr, 2014 1 commit
  23. 02 Feb, 2014 1 commit
  24. 05 Dec, 2013 2 commits
  25. 20 Aug, 2013 2 commits
  26. 07 May, 2013 1 commit
  27. 02 May, 2013 1 commit
  28. 04 Jan, 2013 1 commit
  29. 26 Sep, 2012 1 commit
  30. 23 Oct, 2011 1 commit
  31. 11 Oct, 2011 1 commit
  32. 19 Jun, 2011 1 commit
  33. 29 Jan, 2011 1 commit
  34. 10 Jan, 2011 1 commit
    • ttuegel's avatar
      Tracking enabled/disabled TestSuites in PackageDescription. · f0a2d5e3
      ttuegel authored
      This patch adds the 'testEnabled' field to TestSuite. It's 
      undesirable to track build status information in the static package 
      description, but there is no better solution at this time. This 
      patch has the side-effect of fixing several TODOs in 
      Distribution.Simple.Configure.
      f0a2d5e3
  35. 03 Sep, 2010 1 commit
  36. 07 Jun, 2010 1 commit
  37. 27 May, 2010 1 commit
    • ttuegel's avatar
      Check for duplicate testsuite names · 52166dd3
      ttuegel authored
      Ticket #215 (Overhaul support for packages' tests). During 
      package configuration, check for testsuites with the same name 
      as other testsuites or executables.
      52166dd3