You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(Imported from Trac #345, reported by cjs on 2008-08-27)
I've noticed a few issues with cabal for which I have a proposed solution.
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.
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.
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.
The text was updated successfully, but these errors were encountered:
We're cleaning up the bug tracker to make it useful again and are thus closing bugs that haven't seen any activity in a long time. Please re-open (or file a new bug) if the problem reappears.
(Imported from Trac #345, reported by cjs on 2008-08-27)
I've noticed a few issues with cabal for which I have a proposed solution.
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.
The text was updated successfully, but these errors were encountered: