[Haskell-cafe] Extending Cabal's Preprocessors for GSoC?

[Diego Echeverri]

Hi guys!

Thomas Schilling suggested me to cross-post this here. Basically
I'm thinking about the possibility of extending Cabal's
Preprocessor mechanism for the GSoC. I've been working to provide
uuagc with a Custom build mechanism for Cabal and in this process
I have stumbled upon some difficulties (Dependency resolution and
configurability).

I believe is possible to extend the current preprocessing
mechanism to provide the following:

* Independence from physical representation (Currently the module
  is assumed to be built from a single file with the same name that
  the module)

* Dependency checks (precompile when one of the files on which it
  depends changed. I had to trick cabal and duplicate
  functionality to do this for uuagc. There should be a better
  way!)

* Composability (Add the ability to chain existing preprocessors)

* Configurabily (Make easier to add configuration sections to the
cabal file. I've been using "x-" sections but I guess is possible
to make it look like the already-supported preprocessors).

Any feedback about this?
Suggestions are greatly appreciated.
Diego Echeverri


On Mon, Mar 15, 2010 at 10:33 AM, Thomas Schilling
<nominolo at googlemail.com> wrote:
> 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
>>