#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
_______________________________________________
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
