#815: Feature Request: Translate buildplan to makefile
----------------------------+-----------------------------------------------
Reporter: guest | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: Cabal library | Version: 1.8.0.6
Severity: normal | Keywords: makefile, make
Difficulty: unknown | Ghcversion:
Platform: |
----------------------------+-----------------------------------------------
For the following reasons, I would sometimes like to be able to use GNU
make as my build system, but still get cabal's excellent dependency
version calculations.
Here are the main situations when I wish I had make:
* Whenever I want cabal to do something that is not already common
practice for cabal packages, I end up having to write a bunch of code in
Setup.hs, hacking hooks, and whatnot. This always feels dirty and time
consuming.
* Cabal doesn't yet support parallel builds.
* Cabal files that list many libraries or many executables do a lot of
redundant work and the user doesn't have a fine grained way to specify
which executables or libraries to build without going to a lot of extra
configuration in the cabal file to add flags.
* All modifications to the .cabal file require a full project rebuild,
even when the changes do not impact the source or build plan.
* I need to introspect the build. Perhaps it's not going as planned and
I want to debug it. My only recourse at the moment is --verbose=3.
I find that with the current API, using make and cabal's dependency
calculations are mutually exclusive.
I think the happy medium here is translating the LocalBuildInfo to a
makefile (or part of a makefile). Ideally this makefile could be
optionally included into another makefile. The expectation would be that
the generated makefile is treated as an autogenerated file (eg., not
checked into source control or statically placed on hackage). Instead
it's regenerated during the configure step and then cabal or the user can
invoke make to run the targets.
I believe this would give us parallel builds, allow us to reuse more and
recompile less, and allow us to examine the build plan. And all this
would be possible by leveraging the nice statically checkable, declarative
package specifications we have instead of mucking about with configure
scripts or trying to write an unstructured makefile from hand and getting
the rules subtly wrong. I could imagine it putting us into a harmonious
state where we get the best of both worlds.
--
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/815>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects
_______________________________________________
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
