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 <nomin...@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 <diegoe...@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-de...@haskell.org >> http://www.haskell.org/mailman/listinfo/cabal-devel >> _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
