Changes between Version 9 and Version 10 of Commentary/GSoCMultipleInstances


Ignore:
Timestamp:
May 22, 2012 10:46:27 PM (2 years ago)
Author:
phischu
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/GSoCMultipleInstances

    v9 v10  
    66== Released and Unreleased packages == 
    77 
    8 If we cabal install a package that is released on hackage we call this a clean install. Those should not be used to satisfy dependencies but rather to bring a package into scope in ghci to play with it. If we cabal install an unreleased package we call this a dirty install. 
     8If we cabal install a package that is released on hackage we call this a clean install. Those should not be used to satisfy dependencies but rather to bring a package into scope in ghci to play with it. If we cabal install an unreleased package we call this a dirty install. I assume in that the source code for a released package is uniquely identified by its version number. For unreleased packages this is not the case. 
    99 
    1010== The cabal hash == 
    1111 
    12 The idea is to identify installed packages by a hash of the information needed to build them. 
    13 This hash is the new InstalledPackageId. 
    14 The new installation directory for each instance is $libdir/$pkgid/$installedpackageid. 
    15 The hash is computed during installation in installLib as well as during registration in generateRegistrationInfo. 
     12The idea is to identify installed packages by a hash of the information needed to build them. This hash is the new InstalledPackageId. The new installation directory for each instance is $libdir/$pkgid/$installedpackageid. The hash is computed during installation in GHC.installLib as well as during registration in GHC.generateRegistrationInfo. 
    1613 
    1714The hash contains the following information: 
    1815 
    19 The hashes of all the packages that are actually used for compilation. Those are available in the installedPkgs field of LocalBuildInfo. 
     16The hashes of all the package instances that are actually used for compilation. Those are available in the installedPkgs field of LocalBuildInfo. 
    2017 
    21 The compiler, its version and its arguments and the tools and their version and their arguments. Available from LocalBuildInfo also. 
     18The 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. Probably more. 
    2219 
    23 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 but what about unreleased packages? 
     20The 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 and only hash that but what about unreleased packages? From the PackageDescription's library field the exposedModules can be extracted. Also from PackageDescription extraSrcFiles can be extracted. What about the Other Modules? There must be another way. 
    2421 
    25 == Details == 
     22What is ComponentLocalBuildInfo for? 
    2623 
    27 The ABI hash becomes a field of InstalledPackageInfo. (What is it needed for?) 
     24== Other == 
    2825 
    29 For inplace package registration any packages with the same location must be unregistered. 
     26The ABI hash becomes a field of InstalledPackageInfo. 
     27 
     28For inplace package registration any packages with the same location must be unregistered. For that you must ask for all installed packages, find the one that is installed to that location and unregister it. 
    3029 
    3130== Open Questions ==