[Hackage] #345: Build Tree Proposal

Hackage trac at galois.com
Tue Aug 26 23:58:26 EDT 2008

#345: Build Tree Proposal
  Reporter:  cjs            |        Owner:         
      Type:  enhancement    |       Status:  new    
  Priority:  normal         |    Milestone:         
 Component:  Cabal library  |      Version:
  Severity:  normal         |     Keywords:         
Difficulty:  normal         |   Ghcversion:  6.8.3  
  Platform:  Other Unix     |  
 I've noticed a few issues with cabal for which I have a proposed solution.

 1. Currently, if you have two different executables that use the same
 build     options and mostly the same source, the .o files that they share
 are compiled   twice and stored in separate locations, costing both CPU
 time and disk space.   It would be preferable never to compile a .o file
 more than once with the same  set of options.

 2. It's handy, when using runhaskell and ghci in your source tree, to be
 able   to freely run either on any source file and have them use any
 compiled binaries that are available. With the current way Cabal builds
 things, except in simple  projects with only one target, there is no
 single directory that contains all   of the compiled files. Instead there
 is a separate directory for each target    that contains only the files
 necessary to build that particular target. This    leaves no optimal
 choice for the -hidir and -odir options of runhaskell and     ghci.

 3. It's not uncommon to build several different executables from the same
 set   of source files with the same build options. Currently the
 specificiation for   this is verbose and repetitive, since all options
 must be repeated for every    executable.

 A possible change that would help to mitigate all three of these problems,
 while being fully backward compatable, would be to introduce the concept
 of a   "build tree"; a single build directory that would contain all of
 the object     files built from a given source tree.  This would be
 specified in the cabal     file in the same way that an executable or a
 library is specified, and would    make use of the same hs-source-dirs,
 extensions, build-depends and similar      options.  However, within a
 build section it would be possible also to specify  that specific
 libraries and/or executables be built from that build tree. These
 subsections would use main-is, exposed-modules and similar options that
 are     currently used by top-level executable and library declarations.

 Note that this would require, for GHC builds at least, #179 to be
 implemented, and it would appear to provide the feature requested in #276.

Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/345>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects

More information about the cabal-devel mailing list