Changes between Version 24 and Version 25 of Commentary/GSoCMultipleInstances


Ignore:
Timestamp:
Jun 19, 2012 1:11:40 PM (22 months ago)
Author:
kosmikus
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/GSoCMultipleInstances

    v24 v25  
    77 * ghc-pkg should always add instances to the PackageDB and never overwrite them, 
    88 * ghc --make, ghci, and the configure phase of Cabal should select suitable instances according to some rule of thumb (similar to the current resolution technique), 
     9 * we want to be able to make more fine-grained distinctions between package instances than currently possible, for example by distinguishing different build flavours or "ways" (profiling, etc.) 
    910 * cabal-install should still find an InstallPlan, and still avoid unnecessarily rebuilding packages whenever it makes sense 
    1011 * some form of garbage collection should be offered to have a chance to reduce the amount of installed packages 
     
    6263Picking a random version is a last resort. A combination of installation time and priorities seems rather feasible. It makes conflicts unlikely, and allows to persistently change the priorities of installed packages. Using the order in the package DB is difficult if directories are being used as DBs. Looking at the transitive closure of dependencies makes it hard to define a total ordering of package instances. Adding a complex solver is unattractive unless we find a way to reuse cabal-install's functionality within GHC, but probably we do not want to tie the two projects together in this way. 
    6364 
     65== Build flavours == 
     66 
     67Once we distinguish several package instances with the same version, we have a design decision how precise we want that distinction to be. 
     68 
     69The minimal approach would be to just take the transitive dependencies into account. However, we might also want to include additional information about builds such as Cabal flag settings, compiler options, profiling, documentation, build tool versions, external (OS) dependencies, and more. 
     70 
     71=== The Cabal hash === 
     72 
     73We hash the build configuration of a package that is to be built. cabal-install uses this hash to check if a package is already installed. 
     74 
     75A build configuration consists of the following: 
     76 
     77The Cabal hashes of all the package instances that are actually used for compilation. This is the environment. It is available in the installedPkgs field of LocalBuildInfo which is available in every step after configuration. It can also be extracted from an InstallPlan after dependency resolution. 
     78 
     79The compiler, its version and its arguments and the tools and their version and their arguments. Available from LocalBuildInfo also. More specifically: compiler, withPrograms, withVanillaLib, withProfLib, withSharedLib, withDynExe, withProfExe, withOptimization, withGHCiLib, splitObjs, stripExes. And a lot more. [Like what?] 
     80 
     81The source code. This is necessary because if the source code changes the result of compilation changes. For released packages i would assume that the version number uniquely identifies the source code. A hash of the source code should be available from hackage to avoid downloading the source code. For an unreleased package we need to find all the source files that are needed for building it. Including non-haskell source files. One way is to ask a source tarball to be built as if the package was released and then hash all the sources included in that. 
     82 
     83OS dependencies are not taken into account because i think it would be very hard. 
     84 
     85=== Released and Unreleased packages === 
     86 
     87If we cabal install a package that is released on hackage we call this a clean install. If we cabal install an unreleased package we call this a dirty install. Clean installs are mainly used to bring a package into scope for ghci and to install applications. While they can be used to satisfy dependencies this is discouraged. For released packages the set of source files needed for compilation is known. For unreleased packages this is currently not the case. 
     88 
     89 
    6490 
    6591== Dependency resolution in cabal-install == 
    6692 
    67 "so I see two general options for communicating knowledge about build flavors to the solver: 
     93 
     94There are two general options for communicating knowledge about build flavors to the solver: 
    6895 
    6996(1) "the direct way":  
     
    84111It should be possible to have a garbage collection remove unneeded packages. It has to be interactive because there might be dependencies not known to Cabal and ghc-pkg. Sandboxes are useful for the user to keep track of what should be removable without causing too much damage. 
    85112 
    86  
    87 == The Cabal hash == 
    88  
    89 We hash the build configuration of a package that is to be built. cabal-install uses this hash to check if a package is already installed. 
    90  
    91 A build configuration consists of the following: 
    92  
    93 The Cabal hashes of all the package instances that are actually used for compilation. This is the environment. It is available in the installedPkgs field of LocalBuildInfo which is available in every step after configuration. It can also be extracted from an InstallPlan after dependency resolution. 
    94  
    95 The compiler, its version and its arguments and the tools and their version and their arguments. Available from LocalBuildInfo also. More specifically: compiler, withPrograms, withVanillaLib, withProfLib, withSharedLib, withDynExe, withProfExe, withOptimization, withGHCiLib, splitObjs, stripExes. And a lot more. [Like what?] 
    96  
    97 The source code. This is necessary because if the source code changes the result of compilation changes. For released packages i would assume that the version number uniquely identifies the source code. A hash of the source code should be available from hackage to avoid downloading the source code. For an unreleased package we need to find all the source files that are needed for building it. Including non-haskell source files. One way is to ask a source tarball to be built as if the package was released and then hash all the sources included in that. 
    98  
    99 OS dependencies are not taken into account because i think it would be very hard. 
    100  
    101 == Released and Unreleased packages == 
    102  
    103 If we cabal install a package that is released on hackage we call this a clean install. If we cabal install an unreleased package we call this a dirty install. Clean installs are mainly used to bring a package into scope for ghci and to install applications. While they can be used to satisfy dependencies this is discouraged. For released packages the set of source files needed for compilation is known. For unreleased packages this is currently not the case. 
    104113 
    105114== Separating storage and selection of packages ==