Changes between Version 1 and Version 2 of Design/BuildSystem


Ignore:
Timestamp:
Aug 21, 2008 8:04:00 AM (6 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Design/BuildSystem

    v1 v2  
    2222    control, and are easily modifiable. 
    2323 
    24   * development is easier, because 'make' will preprocess files 
     24  * Development is easier, because 'make' will preprocess files 
    2525    too.  Right now if you modify a .y or .hsc file, you need 
    2626    to tell Cabal to preprocess again before saying 'make' 
     
    3737    only the build rules. 
    3838 
    39 Here's a more detailed plan: 
     39== Detailed plan == 
    4040 
    4141 
    42   * Modify cabal-bin.hs with a new command to generate the 
     42  * Modify `cabal-bin.hs` with a new command to generate the 
    4343    Makefile bindings for a package, into a file e.g.  
    44     ghc-build.mk 
     44    `ghc-build.mk`.  That is, `cabal-bin.hs` imports the Cabal libraries 
     45    and uses them to support all of Cabal's existing features, plus 
     46    the new one.  
     47 
     48  * There is just one `cabal-bin` executable for 
     49    the whole GHC build tree.   
     50 
     51  * Question: should we rename `cabal-bin.hs` to `ghc-cabal.hs`? 
     52 
     53  * The version of Cabal used by `cabal-bin.hs` does not need to be an up-to-the-minute 
     54    bleeding-edge version.  It should be stable and vary slowly.  We suck a new 
     55    version of Cabal into the GHC build system manually, rather than mirroring the 
     56    Cabal HEAD. 
     57 
     58  * The makefile-generation stuff (which Duncan dislikes) can be removed from Cabal itself. 
     59    In effect, it now lives in `cabal-bin.hs`. 
    4560 
    4661  * libraries/Makefile puts a GNUmakefile into each library 
     
    5166include $(TOP)/cabal-package.mk 
    5267}}} 
     68    The boilerplate in `cabal-package.mk` is written by hand (not generated), and 
     69    contains all the make rules required implement the desired make targets. 
    5370 
    5471  * In each subdir we support various make targets, e.g. 
    55     * `make configure`, configures the package and generates ghc-build.mk 
    56     * `make all`, builds the .a, and registers.  Builds dependencies autoamtically (or perhaps not: calculating dependencies 
     72    * `make configure`, configures the package and uses `cabal-bin` to generate `ghc-build.mk` 
     73    * `make all`, builds the .a, and registers (using `cabal-bin`.  Builds dependencies  
     74      automatically (or perhaps not: calculating dependencies 
    5775      in GHC takes a while, and traditionally we've done this on demand only). 
    58     * `make install` 
     76    * `make install` uses `cabal-bin`. 
    5977 
    60   * libraries/Makefile just invokes make in the subdirs in the  
     78  * Question: do we still have `Setup.hs` in each library directory?  Presumably not. 
     79 
     80  * libraries/Makefile just invokes `make` in the subdirs in the  
    6181    appropriate order. 
    6282 
    63 Improvements for later 
     83== Improvements for later == 
    6484 
    65   * we want dependencies from every object file on the .a files of the 
     85  * We want dependencies from every object file on the .a files of the 
    6686    packages that it depends on.  This way we can make it possible to 
    6787    modify a library module and say 'make' and have everything rebuilt  
     
    6989    we need to know about indirect as well as direct package dependencies. 
    7090 
    71   * build multiple libraries in parallel 
     91  * Build multiple libraries in parallel 
    7292 
    73   * remove the makefile code from Cabal 
     93  * Remove the makefile code from Cabal