id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc	difficulty	ghcversion	platform
345	Build Tree Proposal	cjs		"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.

"	enhancement	new	normal		Cabal library	1.4.0.1	normal				normal	6.8.3	Other Unix