This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 08 Oct, 2016 3 commits
  2. 07 Oct, 2016 1 commit
  3. 06 Oct, 2016 36 commits
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Merge pull request #3919 from ezyang/pr/new-repl-noregister · 4fd559ad
      Edward Z. Yang authored
      Only reregister inplace package if we built it.
      4fd559ad
    • Edward Z. Yang's avatar
      Merge pull request #3672 from ezyang/backpack · 8fa4d2ea
      Edward Z. Yang authored
      Backpack
      8fa4d2ea
    • bardur.arantsson's avatar
      Merge pull request #3937 from 23Skidoo/config-init-more-obvious · f8095ac4
      bardur.arantsson authored
      Make the initial '~/.cabal/config' comment more obvious.
      f8095ac4
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Clarify what hsig writing out is. · 2f93432d
      Edward Z. Yang authored
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      2f93432d
    • Edward Z. Yang's avatar
      Update toComponentsGraph comment. · 399e54a4
      Edward Z. Yang authored
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      399e54a4
    • Edward Z. Yang's avatar
      c2870d7e
    • Edward Z. Yang's avatar
      Add a new 'DefUnitId' type with invariant. · bd3040bd
      Edward Z. Yang authored
      
      
      The DefUnitId invariant says that the UnitId in a DefUnitId
      must in fact be a definite package (either with no holes, or
      fully instantiated.)  This is in constrast to a UnitId,
      which can also identify an indefinite unit identifier.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      bd3040bd
    • Edward Z. Yang's avatar
      Rename IndefModule to OpenModule. · 2e42ca27
      Edward Z. Yang authored
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      2e42ca27
    • Edward Z. Yang's avatar
      Rename IndefUnitId to OpenUnitId. · 62ddf8e0
      Edward Z. Yang authored
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      62ddf8e0
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      1be2b213
    • Edward Z. Yang's avatar
      95710677
    • Edward Z. Yang's avatar
      cabal-install changes for Backpack. · 69cfeec2
      Edward Z. Yang authored
      
      
      Here are the main changes:
      
      Distribution/Client/InstallPlan.hs
          New utility function 'fromSolverInstallPlanWithProgress'
          which is a monadic version of 'fromSolverInstallPlan'.
          This is because, with Backpack, the conversion from
          'SolverInstallPlan' to 'InstallPlan' can fail/log.
      
      Distribution/Client/ProjectPlanning/Types.hs
          OK. A bunch of new information we need to track.
      
          New fields in 'ElaboratedConfiguredPackage':
              elabInstantiatedWith :: ModuleSubst (for --instantiated-with)
              elabLinkedInstantiatedWith :: IndefModuleSubst (intermediate)
              elabModuleShape :: ModuleShape (for mix-in linking)
      
          Here is how all the dependency functions relate to
          one another:
      
              elabOrderDependencies :: [UnitId]
                  Used for nodeNeighbors, this just specifies what needs
                  to be built before we build this module.  These refer
                  either to fully instantiated unit ids (hashed unit id)
                  or uninstantiated unit ids (effectively component id)
                  but never a partially instantiated unit id, since we
                  never have an install item in our plan for a partially
                  instantiated package.
      
                  These dependencies are factored into two parts:
                      elabOrderLibDependencies
                      elabOrderExeDependencies
                  which soley are used to determine if we need to enable
                  executables/libraries of a package we are building
                  (this isn't new)
      
              elabLibDependencies :: [ComponentId]
                  These are the things we pass to Setup using the --dependency
                  flag; so they are JUST ComponentId, not a full on UnitId.
                  The mix-in linking process in Setup will reconstruct the
                  necessary UnitId.
      
              elabExeDependencies :: [ComponentId]
                  These are the things that we must add to the PATH to run.
                  At the moment, this coincides with elabOrderExeDependencies.
      
          For components, there is also:
      
              compLinkedLibDependencies :: [IndefUnitId],
                  The partially instantiated unit ids that GHC would be
                  invoked with, if we were invoking it directly.
                  This is used when we subsequently instantiate components.
      
              compNonSetupDependencies :: [UnitId]
                  Non-setup, ORDER dependencies; i.e., everything that has
                  to be built before us that is not a setup script.
      
      Distribution/Client/ProjectPlanning.hs
          The workhorse.
      
          Essentially, we redo all of the steps from
          Distribution.Backpack.Configure, but in the context of planning an
          entire install plan.  The conversion from SolverInstallPlan
          to InstallPlan is responsible for mix-in linking
          (inside elaborateSolverToComponents); afterwards,
          instantiateInstallPlan is responsible for filling in
          the missing, instantiated packages which we need to compile.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      69cfeec2
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      2acefb28
    • Edward Z. Yang's avatar
      45d75e1f
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      A few cleanups and minor things · 26c67025
      Edward Z. Yang authored
      Add a clarification in packageTemplateEnv
      
      Improve the pre-processing message so we can see which unit is being
      built, not just the source component name.
      
      Debug output while building to print out the installed package info
      when we register information.
      
      Remove a done TODO about making sure the installed package registration
      files do not clash with each other, by including the full UnitId. This
      did not need any code changes here since dislaying the UnitId does the
      right thing.
      26c67025
    • Edward Z. Yang's avatar
      Fixup haddock backpack support · 9e59b862
      Edward Z. Yang authored
      1) Bugfix so that we get library source files from the correct
         directories (it was wrong previously; it only ever looked
         in the library directory)
      2) Search for hsig/lhsig files when looking for source files
      9e59b862
    • Edward Z. Yang's avatar
      Teach GHC how to build indefinite libraries · fa79bdf0
      Edward Z. Yang authored
      These are libraries which don't have any code (uses 'whenHasCode'
      combinator).  In principle this could also be extended to support
      building anything with no code.
      
      Also update 'ghcOptThisUnitId' and 'ghcOptInstantiatedWith' to
      have correct values.
      fa79bdf0
    • Edward Z. Yang's avatar
      Include signatures in SrcDist · 42af3567
      Edward Z. Yang authored
      Count signatures as modules that we have to find, and when searching for
      modules, look for .hsig or .lhsig files (in addition to the usual .hs
      .lhs files)
      42af3567
    • Edward Z. Yang's avatar
      Pre-build, make empty .hsig files for each requirement of the library · beff9e87
      Edward Z. Yang authored
      Part of the GHC/Cabal contract is that we always have a source file
      for everything GHC works on.
      beff9e87
    • Edward Z. Yang's avatar
      Fix up component build directories to avoid clashes · 5173c9e4
      Edward Z. Yang authored
      Now that we can build a component multiple times with
      different instantiations, we need to make sure we give each
      instantiation a different build directory; done in 'buildDir'.
      5173c9e4
    • Edward Z. Yang's avatar
      Generate package registraion with instantiation info · ef7235c7
      Edward Z. Yang authored
      Correctly setup 'instantiatedWith' in 'InstalledPackageInfo'.
      
      Also ensure that there are no duplicate entries in 'depends'
      (I couldn't find the root cause for duplication, so I just
      put the test here.)
      ef7235c7
    • Edward Z. Yang's avatar
      allLibModules now includes every signature in the package · 2515cc28
      Edward Z. Yang authored
      These may NOT be explicitly specified in the Cabal file;
      we read it off of 'componentInstantiatedWith'.
      2515cc28
    • 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
      Add the bulk of the new Backpack code · f2840cca
      Edward Z. Yang authored
      This will shortly be used in the package configuration step.
      
      Distribution/Utils/Progress.hs
          A copy of the Progress monad from cabal-install solver, which we use
          to report failure and logging from otherwise pure code.
      
      Distribution/Backpack/ModSubst.hs
          Defines a type class ModSubst for semantic objects that can have
          module substitutions defined over them.  Helps us define ModSubst
          functorially.
      
      Distribution/Backpack/ModuleScope.hs
          A module scope represents the set of required and provided modules
          which are "in scope", i.e., available for import and mix-in linking.
          This is not a simple mapping from module name to module, as we're
          permitted to have conflicting definitions for a module name as long
          as we don't actually use it.  There's a comment which explains this
          more clearly in the file.  These are based off of 'IndefModule'
          because not all modules in scope are necessarily fully instantiated.
      
      Distribution/Backpack/ModuleShape.hs
          A module shape describes the provisions and requirements of a
          library.  It's similar to a module scope, except that every
          export must be unambiguous; it too is based off of 'IndefModule'.
      
      Distribution/Backpack/FullUnitId.hs
          An 'IndefUnitId' is not guaranteed to record a module substitution
          (it could be opaquely represented as a hash); a 'FullUnitId',
          however, IS guaranteed to do so.  Given, for example, an installed
          package database, we can map opaque 'UnitId' into their expanded
          representation.  This can be important to handle obscure unification
          problems when mix-in linking.
      
      Distribution/Backpack/UnifyM.hs
          The unification monad, unifiable variants of Module/UnitId (with
          conversions to and from), and low-level unification operations on
          them.  Uses 'UnionFind' heavily.
      
          There is some commented out support for handling recursive
          unification.  At present there is no surface syntax for representing
          such situations.  (We would also need DFA minimization to
          canonicalize these regular trees.)
      
      Distribution/Backpack/MixLink.hs
          The actual implementation of mix-in linking, on top of the
          unification monad 'UnifyM'.  The key function is 'mixLink',
          which takes two module scopes and links them together.
      
      Distribution/Utils/LogProgress.hs
          The progress monad, specialized with LogMsg traces and Doc
          errors.  We provide a function to run such computations,
          outputting traces according to their 'Verbosity' and 'die'ing
          if there is an error.
      
      Distribution/Backpack/ComponentsGraph.hs
          A small helper function for handling the source-level graph
          of components (so, just the relationship between stanzas
          in a Cabal file.)  This components graph will eventually get
          elaborated into a more complex graph with instantiations, etc.
      
      Distribution/Backpack/Id.hs
          A helper module which now contains the functions for computing
          component identifiers and compatibility package keys.  This
          functionality used to live in Distribution.Simple.Configure
          but I split it out.  There are also adjustments to handle
          the new Backpack functionality.
      
      Distribution/Backpack/ConfiguredComponent.hs
          A configured component is one for which we've resolved all
          source level dependencies (e.g., every entry in build-depends,
          we know the specific transitive versions of each thing
          we're going to use.)  That means we have a 'ComponentId' for
          this component.  This module also contains functions for
          creating a 'ConfiguredComponent' from a source 'Component'.
      
      Distribution/Backpack/LinkedComponent.hs
          A linked component is one which we have done mix-in linking
          for, so we know its 'IndefUnitId' and its 'IndefUnitId'
      dependencies.
          This module calls out to mix-in linking to actually do linking.
          The workhorse, in a sense!
      
      Distribution/Backpack/ReadyComponent.hs
          This module implements the instantiation process, where we
          zip through all of the fully instantiated components, and
          recursively instantiate their dependencies, so that we
          get a separate linked component per thing we need to
          compile, and also finishes off any top-level indefinite
          components.  This gives us the final 'UnitId' for our
          units.
      
          This functionality is reimplemented in a different way in
          cabal-install; the assumptions are slightly different (in
          particular, in the library we can't assume we have access to all
          packages to build them; but in cabal-install we can assume it) so I
          didn't try to abstract over both implementations.
      
      Distribution/Backpack/PreExistingComponent.hs
          This is a "interoperability" data type which identifies
          precisely the information from a 'LinkedComponent' that
          can be derived from an 'InstalledPackageInfo'.
      f2840cca
    • 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
      Rename .cabal required-signatures field to signatures · 8d31f43b
      Edward Z. Yang authored
      Change of .cabal file syntax: rename @required-signatures@ field to
      just @signatures@. Update the parser and error messages that mention
      the field.
      
      Also rename the corresponding field in the Library type.
      8d31f43b