[Hackage] #815: Feature Request: Translate buildplan to makefile

Hackage cvs-ghc at haskell.org
Thu Mar 17 10:07:01 CET 2011

#815: Feature Request: Translate buildplan to makefile
  Reporter:  guest          |        Owner:                
      Type:  enhancement    |       Status:  new           
  Priority:  normal         |    Milestone:                
 Component:  Cabal library  |      Version:       
  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
   * 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

More information about the cabal-devel mailing list