This project is mirrored from https://github.com/haskell/Cabal.
Pull mirroring updated .
- 08 Oct, 2016 2 commits
-
-
Mikhail Glushenkov authored
-
Mikhail Glushenkov authored
Already fixed in the parent module in 20e35704. Fixes #3915.
-
- 06 Oct, 2016 38 commits
-
-
Edward Z. Yang authored
Only reregister inplace package if we built it.
-
Edward Z. Yang authored
Backpack
-
bardur.arantsson authored
Make the initial '~/.cabal/config' comment more obvious.
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
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:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
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:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu>
-
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.
-
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
-
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.
-
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)
-
Edward Z. Yang authored
Part of the GHC/Cabal contract is that we always have a source file for everything GHC works on.
-
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'.
-
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.)
-
Edward Z. Yang authored
These may NOT be explicitly specified in the Cabal file; we read it off of 'componentInstantiatedWith'.
-
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.
-
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'.
-
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'.
-
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.
-
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.
-
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.
-
Edward Z. Yang authored
New GhcOptions fields, 'ghcOptInstantiatedWith' for @-instantiated-with@ and 'ghcOptNoCode' for @-fno-code@.
-
Edward Z. Yang authored
We will use this when building indefinite libraries.
-