SoC / Cabal project proposal: specify Setup.hs dependencies

I've been wanting to share code between cabal projects for some time, and I finally had a chance to write up the rough idea as a simple proposal. Here's the description, with links to the SoC trac and reddit haskell_proposals pages. SoC ticket: http://hackage.haskell.org/trac/summer-of-code/ticket/1602 Reddit: http://www.reddit.com/r/haskell_proposals/comments/ge1zp/cabal_dependency_sp... Non-standard builds often need to implement specific build steps in Setup.hs, specifying a build-type: Custom in the project cabal file. The user hook system works reasonably well for modifying or replacing the specific sub steps of a build, but *implementing* anything more than the simplest logic in Setup.hs is very difficult. A great deal of this difficulty stems from the lack of library support for code in Setup.hs. Adding a cabal section that specifies a build-depends: for Custom (and possibly other) build types would allow developers to reuse build code between projects, to share build system modifications on hackage more easily, and to prototype new additions to cabal. Setup.hs *can* allow arbitrarily complex build system manipulations; however, it is not practical to do so because the infrastructure surrounding Setup.hs doesn't promote code reuse. The addition of dependencies that cabal-install would install prior to building setup.hs and issuing the build would enable developers to produce custom builds that perform complex operations that utilize the high-quality libraries available on hackage. Furthermore, this would provide the means to prototype (and distribute) new cabal / cabal-install features before integrating experimental code into the stable tools. I'm interested in thoughts / feedback about the idea, as well as hearing from anyone interested in pursuing this as a summer of code project :) Thanks! --Rogan

On Tue, Mar 29, 2011 at 1:26 PM, Rogan Creswick
I've been wanting to share code between cabal projects for some time, and I finally had a chance to write up the rough idea as a simple proposal. Here's the description, with links to the SoC trac and reddit haskell_proposals pages.
SoC ticket: http://hackage.haskell.org/trac/summer-of-code/ticket/1602
Reddit:
http://www.reddit.com/r/haskell_proposals/comments/ge1zp/cabal_dependency_sp...
Non-standard builds often need to implement specific build steps in Setup.hs, specifying a build-type: Custom in the project cabal file. The user hook system works reasonably well for modifying or replacing the specific sub steps of a build, but *implementing* anything more than the simplest logic in Setup.hs is very difficult.
A great deal of this difficulty stems from the lack of library support for code in Setup.hs. Adding a cabal section that specifies a build-depends: for Custom (and possibly other) build types would allow developers to reuse build code between projects, to share build system modifications on hackage more easily, and to prototype new additions to cabal.
Setup.hs *can* allow arbitrarily complex build system manipulations; however, it is not practical to do so because the infrastructure surrounding Setup.hs doesn't promote code reuse. The addition of dependencies that cabal-install would install prior to building setup.hs and issuing the build would enable developers to produce custom builds that perform complex operations that utilize the high-quality libraries available on hackage. Furthermore, this would provide the means to prototype (and distribute) new cabal / cabal-install features before integrating experimental code into the stable tools.
I'm interested in thoughts / feedback about the idea, as well as hearing from anyone interested in pursuing this as a summer of code project :)
I really like the idea behind this proposal. I've had some rather hairy Setup.hs files that would have benefited from being able to use external packages. This could also be really nice when it comes to writing custom test/benchmarking/etc. hooks, by letting you factor out a lot of that common code into reusable libraries. -Edward

On Tue, Mar 29, 2011 at 4:39 PM, Edward Kmett
On Tue, Mar 29, 2011 at 1:26 PM, Rogan Creswick
wrote: I've been wanting to share code between cabal projects for some time, and I finally had a chance to write up the rough idea as a simple proposal. Here's the description, with links to the SoC trac and reddit haskell_proposals pages.
SoC ticket: http://hackage.haskell.org/trac/summer-of-code/ticket/1602
Reddit:
http://www.reddit.com/r/haskell_proposals/comments/ge1zp/cabal_dependency_sp...
Non-standard builds often need to implement specific build steps in Setup.hs, specifying a build-type: Custom in the project cabal file. The user hook system works reasonably well for modifying or replacing the specific sub steps of a build, but *implementing* anything more than the simplest logic in Setup.hs is very difficult.
A great deal of this difficulty stems from the lack of library support for code in Setup.hs. Adding a cabal section that specifies a build-depends: for Custom (and possibly other) build types would allow developers to reuse build code between projects, to share build system modifications on hackage more easily, and to prototype new additions to cabal.
Setup.hs *can* allow arbitrarily complex build system manipulations; however, it is not practical to do so because the infrastructure surrounding Setup.hs doesn't promote code reuse. The addition of dependencies that cabal-install would install prior to building setup.hs and issuing the build would enable developers to produce custom builds that perform complex operations that utilize the high-quality libraries available on hackage. Furthermore, this would provide the means to prototype (and distribute) new cabal / cabal-install features before integrating experimental code into the stable tools.
I'm interested in thoughts / feedback about the idea, as well as hearing from anyone interested in pursuing this as a summer of code project :)
I really like the idea behind this proposal.
I've had some rather hairy Setup.hs files that would have benefited from being able to use external packages. This could also be really nice when it comes to writing custom test/benchmarking/etc. hooks, by letting you factor out a lot of that common code into reusable libraries.
Yes. And I think it would also make it possible solve this bug as a sort of "extension" to cabal: http://hackage.haskell.org/trac/hackage/ticket/815 http://hackage.haskell.org/trac/hackage/ticket/815 The summary of that ticket is: translate buildplans (after dependency resolution) into concrete makefile (or inputs for other build systems, SCons, etc). If the meat of the proposal is too little for a GSoC project, then building a solution for that bug would be a nice way to roundout the student's time :) Although, I think probably to do it right and properly test it, just this feature could take a full summer. Just my $0.02! Jason
participants (3)
-
Edward Kmett
-
Jason Dagit
-
Rogan Creswick