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

[Hackage]

#815: Feature Request: Translate buildplan to makefile
-----------------------------+----------------------------------------------
  Reporter:  guest           |        Owner:         
      Type:  enhancement     |       Status:  closed 
  Priority:  normal          |    Milestone:         
 Component:  Cabal library   |      Version:  1.8.0.6
  Severity:  normal          |   Resolution:  wontfix
  Keywords:  makefile, make  |   Difficulty:  unknown
Ghcversion:                  |     Platform:         
-----------------------------+----------------------------------------------

Comment(by duncan):

 Replying to [comment:2 guest]:
 > Where is the documentation for this feature of getting the automated
 package management?  The user guide doesn't appear to discuss it.

 It's in the Cabal spec:

 http://haskell.org/cabal/proposal/x138.html#AEN226

 > It seems like actually you have to make your own tool on top of cabal or
 you have to implement the logic again and again in every project that
 wants it (inside Setup.hs).

 The Setup.hs just provides a standard command line interface. Tools are
 expected to work with any Setup.hs that implements the interface
 correctly. The Setup.hs does not need to depend on the Cabal library.

 That's the theory. What the spec misses out however is a mechanism for the
 Setup.hs to depend on other Cabal packages. It's not prevented but it's
 essentially an untracked dependency. That's something that could be
 improved.

 > If GHC needs this functionality, and other non-ghc projects would
 benefit as well, what is the justification for not implementing it as part
 of the Cabal library?

 Because different systems want to do it differently. The code that was
 previously in the Cabal library for this was highly ghc specific and not
 widely useful which is why we moved it into the ghc build system rather
 than in the Cabal lib.

 > One thing I can't do with cabal that I can do with all other build
 systems I've used is to define new rules for processing files.  For
 example, if I made a new preprocessor for Haskell source I would have to
 write custom code in every Setup.hs that needs the preprocessor currently.
 Being able to generate a build plan as a makefile would make it so that
 custom preprocessor rules could be inserted easily by end users without
 having to resort to hacking their Setup.hs.

 Prehaps I'm missing something. I don't see how users adding a build rule
 for a preprocessor to their package's Makefile is different to adding it
 to their package's Setup.hs. Perhaps the Makefile is a nicer DSL, but
 that's a slightly different point.

 The "Simple" build system actually has an almost nice way of defining
 preprocessors. You just give the file extension to look for and the code
 to run.

 > For me, modifying Setup.hs is a last resort.  It's a desperate measure.
 Being forced to reimplementing the build logic for every project in a
 general purpose language is exactly the problem that build system DSLs
 like Make were designed to solve.  That's why I see writing custom
 Setup.hs to do anything that isn't trivial as a step backwards.

 It's certainly the case that the Simple build system does not have a nice
 easy extension mechanism.

 There's two separate points here:

  * The Cabal spec says you can put whatever you like in the Setup.hs. This
 gives maximum flexibility. Implementing a build system is not trivial
 however (unless like the Make one it just delegates everything).
  * A specific build system (e.g. the Simple one) could provide some more
 restricted but easier to use extension DSL.

 The reason I think we do not yet have a nicer extension mechanism in the
 Simple build system goes back to the fact that it is not based on a
 modular dependency framework. If it were, it would be much easier to
 extend. Trying to make it far more extensible in its current state would
 be a bit of a nightmare. We did have a GSoC project on this (using a
 dependency based framework) but didn't get as far as we'd like. It's
 doable, it's just quite a bit of work. Strangely, the poor quality of the
 Simple build system has not been the biggest thing that users complain
 about, so it does not float to the top of the TODO list.

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/815#comment:3>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects