Google summer of code in Cabal?

[Thomas Schilling]

Yes, you sent it to the right list.  In fact for discussing summer of
code it might not be a bad idea to cross-post to haskell-cafe to get
some feedback from Cabal users.

In my experience, it is most important for Summer of Code to have a
clearly defined set of "deliverables", i.e., have a good idea of what
features you want to have working at the end of the 10 weeks.  (It's
actually 12 weeks, but the last 2 weeks are expected to be used for
documenting stuff.)

Your problem description sounds plausable, but for a GSoC project it's
good to also have an idea how to solve the problem.  E.g., do you plan
to build a custom framework or just extend Cabal to support more kinds
of preprocessors?

Duncan and others have been working on a true dependency tracking
system similar to Make, but I think there are too many open questions
to turn that into a GSoC project just yet.  It does raise the
question, however, how much overlap there would be with your idea.
Maybe you can find a well-defined subset?

In any case, try to ask haskell-cafe for feedback and apply for both
ideas.  I think you can apply for up to 10 projects, so it's no
problem to apply for more than one.  But keep in mind that the quality
of the proposals matters.

On 14 March 2010 01:40, Diego Echeverri <diegoeche at gmail.com> wrote:
> Hi guys!
>
> I was wondering about the possibility to work on Cabal for the
> summer of code.  I've been helping one of my teachers to
> provide (improve) a "plugin" for the uuagc (I haven't spent too
> much time on it, but here's the fork I'm working on
> http://github.com/diegoeche/uuagc). I have found how flexible the
> cabal libraries are but also some things haven't been
> straightforward to do (I've been using Cabal 1.6.0.3).
>
> Basically there's seems to be an assumption of a one-to-one
> relation of modules and the sources of the files which is not
> followed by the uuagc pre-processor. I can use List.ag and inside
> of it use an include declaration to List-Data.ag. If I modify
> List-Data.ag cabal won't precompile it again because it will only
> check dates against List.ag (cabal doesn't know that the
> file that generates List.hs depends not only in List.ag). I had
> to override the build hook, duplicate the check (this time
> getting all the dependencies) and delete the generated file to
> trick cabal to precompile again... and well... that's seems quite
> a nasty hack to me.
>
> This assumption also affect the possibility to make the output of
> the pre-processor not necessarily an .hs file (and not necessarily
> carrying the same name). Checking the code for the
> pre-processors (Distribution.Simple.PreProcess) I noticed it would
> be good to have the possibility to chain pre-processors. I believe
> both issues are pretty much connected.
>
> I also found the following proposal here:
> http://hackage.haskell.org/trac/summer-of-code/ticket/1581 which
> sound also interesting to me. (and there's already a mentor
> available!)
>
> Do you think this could be a good project for the summer of code?
> Maybe any other ideas I should explore? Did I write to the right
> list? (please excuse me if I didn't)
>
> Thanks!
> Diego Echeverri
>
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/cabal-devel
>



-- 
Push the envelope.  Watch it bend.