[Haskell-cafe] SoC / Cabal project proposal: specify Setup.hs dependencies

Jason Dagit dagitj at gmail.com
Wed Mar 30 01:53:09 CEST 2011


On Tue, Mar 29, 2011 at 4:39 PM, Edward Kmett <ekmett at gmail.com> wrote:

>
>
> On Tue, Mar 29, 2011 at 1:26 PM, Rogan Creswick <creswick at gmail.com>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_specifications_for_setuphs/
>>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110329/3adb27cd/attachment.htm>


More information about the Haskell-Cafe mailing list