Changes between Version 3 and Version 4 of Commentary/Packages


Ignore:
Timestamp:
Jul 10, 2009 11:00:17 AM (6 years ago)
Author:
simonmar
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Packages

    v3 v4  
    4949== Design constraints == 
    5050 
    51  1. We want [wiki:Commentary/Compiler/RecompilationAvoidance] to work.  So that means symbol names should not contain any information that varies too often, such as the ABI hash of the module or package.  The ABI of an entity should depend only on its definition, the definitons of the things it depends on, and compiler settings. 
     51 1. We want [wiki:Commentary/Compiler/RecompilationAvoidance] to work.  So that means symbol names should not contain any information that varies too often, such as the ABI hash of the module or package.  The ABI of an entity should depend only on its definition, and the definitons of the things it depends on. 
    5252 
    5353 2. We want to be able to detect ABI incompatibility.  If a package is recompiled and installed over the top of the old one, and the new version is ABI-incompatible with the old one, then packages that depended on the old version should be detectably broken using the tools. 
     
    7474    but it may contain the package name and API version for documentation. 
    7575  * `PackageSymbolId`: the symbol prefix used in compiled code. 
    76   * `PackageLibId`: the package Id placed in library files (static and shared). 
     76  * `PackageLibId`: the package Id in the name of a compiled library file (static and shared). 
    7777 
    7878=== Detecting ABI incompatibility === 
     
    8585  * If, say, package P-1.0 is recompiled and re-installed, the new instance of the package will almost 
    8686    certainly have an incompatible ABI from the previous version.  We give the new package a distinct 
    87     `InstalledPackageId`, so that packages that depend on the old P-1.0 will now be broken. 
     87    `InstalledPackageId`, so that packages that depend on the old P-1.0 will now be detectably broken. 
    8888 
    8989  * `PackageSymbolId`: We do not use the `InstalledPackageId` as the symbol prefix in the compiled code, because  
     
    9191    new unique `InstalledPackageId` (e.g. when reconfiguring the package), we would have to recompile 
    9292    the entire package.  Hence, the `PackageSymbolId` is picked deterministically for the package, e.g. 
    93     it can be just the package name/version. 
     93    it can be the `PackageIdentifier`. 
    9494 
    95   * `PackageLibId`: ee do want to put the `InstalledPackageId` in the name of a library file, however.  This allows 
    96     ABI compatibility to be detected by the linker.  This is important for shared libraries too: we 
     95  * `PackageLibId`: we do want to put the `InstalledPackageId` in the name of a library file, however.  This allows 
     96    ABI incompatibility to be detected by the linker.  This is important for shared libraries too: we 
    9797    want an ABI-incompatible shared library upgrade to be detected by the dynamic linker.  Hence, 
    9898    `PackageLibId` == `InstalledPackageId`. 
     
    102102 * The simplest scheme is to have an identifier for each distinct ABI, e.g. a pair of the package name and an integer 
    103103   that is incremented each time an ABI change of any kind is made to the package.  The ABI identifier 
    104    by the package, and is used as the `PackageSymbolId`.  Since packages with the same `PackageAbiId` 
     104   is declared by the package, and is used as the `PackageSymbolId`.  Since packages with the same ABI identifier 
    105105   are ABI-compatible, the `PackageLibId` can be the same as the `PackageSymbolId`. 
    106106 
     
    109109   * the ABI major version is as before, the package name + an integer.  This is also the `PackageSymbolId`. 
    110110   * the ABI minor version is an integer that is incremented each time the ABI is extended in a compatible way. 
    111    * package dependencies in the database specify the major+minor version they require.  The may be satisfied by  
    112      a greater minor version. 
     111   * package dependencies in the database specify the major+minor ABI version they require, in addition to the 
     112     `InstalledPackageId`.  They may be satisfied by a greater minor version; when upgrading a package with an  
     113     ABI-compatible replacement, ghc-pkg updates dependencies to point to the new `InstalledPackageId`. 
    113114   * `PackageLibId` is the major version.  In the case of shared libraries, we may name the library using the 
    114115     major + minor versions, with a symbolic link from the major version to major+minor. 
     
    122123   incompatible ABI changes in the compiler and RTS at regular intervals anyway.  ABI compatibility is more important 
    123124   between major releases of the compiler. 
     125