[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: 1.4.0.1
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