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
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@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
-- Push the envelope. Watch it bend.