This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 27 Feb, 2017 10 commits
    • Duncan Coutts's avatar
      Add and improve a couple comments · 942fc0e5
      Duncan Coutts authored
      942fc0e5
    • Duncan Coutts's avatar
      Add a new 'all' form of target selector · df8ccce1
      Duncan Coutts authored
      Extend TargetSelector with a TargetAllPackages constructor with the
      corresponding concrete command line syntax 'all'. The interpretation of
      this is extended for all commands to be the same as if the list of all
      packages local to the project were given.
      
      Since the concrete syntax for the meta-target 'all' can in principle
      clash with a package 'all' or a component 'all', this short form of
      syntax is made to be ambigious with the existing short forms for
      packages or components, and new more qualified forms are added.
      
      This means that a user writing 'cabal build all' in a project where
      there is a local package 'all' or a component 'all' in the package in
      the cwd (but not any package 'all' as a dependency or any component
      'all' in any package other than the one in the cwd), will be informed
      that the syntax is ambigious and will be told the more qualified forms
      of the possible targets. These would be ':all' and 'pkg:all'. The use of
      the usual ':' separator with an empty string is the explicit indicator
      of a meta namespace. Since 'pkg:all' itself is also potentially
      ambigious with a package named 'pkg' containing a component 'all' then
      there is a further qualified form ':pkg:all' to select the package named
      'all'.
      
      This more qualified syntax need only be used in these highly unusual
      ambigious cases and the user will be informed. The intention, as has
      been the case previously, is to allow a normal syntax that is short and
      convenient but potentially ambigious in rare cases, while still allowing
      all cases to be expressed unambigiously.
      df8ccce1
    • Duncan Coutts's avatar
      Split getting project config from making the install plan · a05b8a07
      Duncan Coutts authored
      Previously we had a rebuildInstallPlan that does everything up to
      producing the elaborated install plan. This included reading the project
      config and all the local package description files etc.
      
      It is useful to split this latter aspect out separately. The reason for
      this is that we would really prefer to resolve command line build
      targets without first having to run the solver and produce the
      elaborated install plan. We would prefer to be able to report mistakes
      in the build targets more or less instantly rather than having to wait
      many seconds (or sometime more) before being able to report problems.
      Worse, with the current scheme the solver may fail to find a solution
      and so we'll end up reporting that rather than the problem with the
      user's build target. Indeed problems with a build target are most likely
      to happen when the project config is messed up (or not what users
      expect, or before they understand the model) and those are the cases
      where it's most likely that there is no project solution.
      
      So this is a step towards being able to do all target resolution prior
      to solving.
      a05b8a07
    • Duncan Coutts's avatar
      Move rendering of CannotPruneDependencies to CmdBuild · 259a88cd
      Duncan Coutts authored
      The --only-dependencies it is only used in build, so we move the
      rendering of the errors that arise from that to that build command
      module so the error message text can be more context specific.
      259a88cd
    • Duncan Coutts's avatar
    • Duncan Coutts's avatar
      New infrastructure for collecting info on available targets · d02bc2f0
      Duncan Coutts authored
      This is one major part of a new implementation of translating from high
      level user intentions of what to build into the detail of what specific
      components to build.
      
      This part collects and summarises information on what component are
      available as targets. Each available target one has enough status info
      to determine if we can possibly select the target or if not why not.
      
      This information will be used by each command (build, repl, test etc) to
      select the specific targets that a user intention refers to (and to
      provide them enough information to be able to produce reasonable error
      messages).
      
      Collecting and summarising this info is unfortunately non-trivial
      because as part of install plan elaboration we omit components that
      cannot be built but these are still components that users could try to
      refer to, so we have to reconstruct the info about the omitted
      components. It's plausible that we may want to revise the elaborated
      install plan representation to make this easier.
      d02bc2f0
    • Duncan Coutts's avatar
      Change pruneInstallPlanToTargets to take ComponentTargets · bd177197
      Duncan Coutts authored
      Previously it took the specification for the targets to build in terms
      of PackageTarget which is a high-ish level specification of which
      components to build. It is high level in the sense that it says things
      like BuildDefaultComponents which still have to be elaborated into the
      specific components.
      
      This elaboration from the higher level intention of what to build into
      what components to build specifically has to vary between different
      commands (build, repl, run, test, bench) and it can also fail. These
      features make it not a good fit to do within plan pruning. Instead it
      is better to have plan pruning take the lower level specification of
      what to build in terms of components and to do the conversion of high
      level to low level separately. That will allow us to do it differently
      for different commands and deal with failures better.
      
      This patch does one step: it changes pruneInstallPlanToTargets from
      taking [PackageTarget] to [ComponentTarget] and as an intermediate step
      in refactoring it converts the existing elaboratePackageTargets code to
      convert from the [PackageTarget] to [ComponentTarget] which is then used
      by the calling code in ProjectOrchestration. The next step will be to
      replace the elaboratePackageTargets with something more flexible and
      that can handle errors better.
      bd177197
    • Duncan Coutts's avatar
      Refactoring: make nubComponentTargets top level · 5fbf262c
      Duncan Coutts authored
      And push compatSubComponentTargets inside nubComponentTargets. The
      motivation for this is we'll be exporting nubComponentTargets and using
      it from the ProjectOrchestration as part of revised target handling.
      5fbf262c
    • Duncan Coutts's avatar
      49c1af5c
    • Duncan Coutts's avatar
      Split one of the pruneInstallPlanToTargets passes for clarity · 0b432931
      Duncan Coutts authored
      The pruneInstallPlanToTargets function had two main passes. Split the
      first pass into two passes. This simplifies things a bit and helps
      clarify the fact that setting the root targets is something we do prior
      to taking the dep closure.
      0b432931
  2. 24 Feb, 2017 1 commit
  3. 19 Feb, 2017 4 commits
  4. 08 Feb, 2017 1 commit
    • Duncan Coutts's avatar
      Change Graph.fromList to fromDistinctList and fix conseqeunces · 1440ffd5
      Duncan Coutts authored
      It's really an error to try and build a graph where you have duplicate
      node keys, so remove Graph.fromList and add Graph.fromDistinctList. This
      check is always on, not just an assertion, becuase we get it for free
      given the way Maps can be constructed.
      
      All uses of Graph.fromList are ok to convert to fromDistinctList.
      1440ffd5
  5. 03 Feb, 2017 1 commit
  6. 26 Jan, 2017 3 commits
  7. 24 Jan, 2017 1 commit
  8. 22 Jan, 2017 1 commit
  9. 20 Jan, 2017 1 commit
    • John Ericson's avatar
      Only need to look up internal exes in `exe_map` · 60ca0937
      John Ericson authored
      This map, I am told, only contains component ids for the
      current package, so there is no point of looking for other
      package's exe components in there.
      
      Sent to travis to confirm hypothesis, but amended commit
      to elabote this message.
      60ca0937
  10. 19 Jan, 2017 1 commit
  11. 16 Jan, 2017 1 commit
  12. 12 Jan, 2017 2 commits
  13. 07 Jan, 2017 1 commit
    • Robert Henderson's avatar
      Added qualifier to 'PackageConstraint' data type. · 79d562bf
      Robert Henderson authored
      Refactored PackageConstraint in two ways:
       1) split it into a package name and a 'PackageProperty' to make
          the code a bit cleaner;
       2) changed PackageName to 'Qualified PackageName'.
      
      Added a Binary instance for Qualifier in PackagePath.hs (needed
      for PackageConstraint).
      
      Added pretty-printing code for PackageConstraint.
      
      For now, all the code that creates a PackageConstraint just sets
      the qualifier to 'unqualified', so this commit will not change
      the external behaviour of cabal-install.
      79d562bf
  14. 03 Jan, 2017 1 commit
    • Edward Z. Yang's avatar
      Don't compile signature packages with instantiations. · efe1b211
      Edward Z. Yang authored
      
      
      A signature package is a package that contains only signatures but no
      modules (equivalently, it is a package that has no provisions.)
      
      Previously, we did not treat signature packages any differently from
      normal packages, which, in particular, meant that when we instantiated a
      package using a signature package, we also instantiated the signature
      package.  This is actually pretty useless, because we never actually use
      the instantiated signature (there's no code that actually gets compiled
      in this case).
      
      This patch treats signature packages specially, so that we don't
      actually instantiate dependencies on them.  This means we have
      to compile less packages when handling signatures.  Good!
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      efe1b211
  15. 31 Dec, 2016 1 commit
    • Duncan Coutts's avatar
      Refine the fix for requiring Cabal > 1.20 for Setup.hs · 86490508
      Duncan Coutts authored
      Going along with the existing approach of using a constraint rather than
      altering the deps of custom Setup.hs scripts, but make the constraint
      only apply to Cabal instances that are dependencies of Setup.hs scripts
      not all instances of Cabal.
      
      Also rearrange things a little with a dedicated solver policy function
      for adding a min dep on Cabal versions for setup scripts.
      86490508
  16. 27 Dec, 2016 1 commit
    • Edward Z. Yang's avatar
      Refactor Backpack data structures to be less flexible. · 28af355b
      Edward Z. Yang authored
      
      
      There were a number of fields in 'LinkedComponent' which
      were "too" flexible, in that they were fully determined by
      other fields in the structure.  This refactor deletes those
      fields and replaces them with functions that refer to the
      fields directly.
      
      I also introduce a new type, ComponentInclude, to take
      the place of tuples which were used to represent includes
      (mixins) in Backpack.
      
      There's also more documentation for lots of bits.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      28af355b
  17. 20 Dec, 2016 1 commit
  18. 27 Nov, 2016 1 commit
  19. 17 Nov, 2016 1 commit
  20. 14 Nov, 2016 1 commit
  21. 01 Nov, 2016 1 commit
  22. 31 Oct, 2016 1 commit
  23. 29 Oct, 2016 1 commit
    • Jason Dagit's avatar
      Require Cabal >= 1.20 in new-build. (#4051) · 80de7ff4
      Jason Dagit authored
      Constrain Cabal >= 1.20 in all new-build install plans. This solves problems where Cabal 1.18 don't have a good enough API to let us handle the new-style store (we need --dependency flags.)
      
      In the future we plan to relax this to only Setup.hs dependencies.
      
      Fixes issue #3932.
      80de7ff4
  24. 28 Oct, 2016 1 commit
    • Edsko de Vries's avatar
      Add support for foreign libraries. · 382143aa
      Edsko de Vries authored
      A stanza for a platform library looks something like
      
          platform-library test-package
            type:                native-shared
      
            if os(Windows)
              options: standalone
              mod-def-file: TestPackage.def
      
            other-modules:       MyPlatformLib.Hello
                                 MyPlatformLib.SomeBindings
            build-depends:       base >=4.7 && <4.9
            hs-source-dirs:      src
            c-sources:           csrc/MyPlatformLibWrapper.c
            default-language:    Haskell2010
      
      where native-shared means that we want to build a native shared library
      (.so on Linux, .dylib on OSX, .dll on Windows). The parser also
      recognizes native-static but this is not currently supported anywhere.
      The standalone option means that the we merge all library dependencies
      into the dynamic library (i.e., ghc options -shared -static), rather
      than make the created dynamic library just record its dependencies (ghc
      options -shared -dynamic); it is currently compulsory on Windows and
      unsupported anywhere else. The mod-def-file can be used to specify a
      module definition file, and is also Windows specific.
      
      There is a bit of refactoring in Build: gbuild is the old buildOrReplExe
      and now deals with both executables and platform libraries.
      382143aa
  25. 25 Oct, 2016 1 commit
    • Edward Z. Yang's avatar
      Drop version check when resolving package names. · af24cefe
      Edward Z. Yang authored
      
      
      In #4017, hvr reported that when he used --allow-older/--allow-newer,
      there was an assert failure in toConfiguredComponent.  Indeed
      the problem was that toConfiguredComponent was testing version
      ranges of build-depends to determine which package to select, but
      there was no satisfying one (since the build-depends field had
      not been updated.)
      
      After thinking about this for a bit, it seemed a bit bogus for
      us to be doing another version check at this late phase; we
      already picked dependencies earlier in the configuration process.
      So I decided to drop it.
      
      To drop it, however, I needed to remove support for a feature (discussed
      in #4020), which uses version ranges to disambiguate whether or not a
      dependency is on an external package or an internal package.  This
      feature doesn't seem to be very useful.  If someone asks, I'll
      check on Hackage to see if anyone is using it.
      
      Also added some useful extra debug info.
      
      Fixes #4020 and #4017
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      af24cefe