It seems that the build targets feature I previously wrote about is somewhat more work than I expected, mainly in terms of integration with the Eclipse GUI. With my university classes starting soon, and some work that I’ve been pushing ahead of me throughout GSoC, I am unable to finish this in time.

Therefore, I’ve parked the build target feature in a branch and decided to officially put a stop to this project for the time being. I have updated the EclipseFP web site to reflect the work I did. I also rolled a release that you can pull in using the Eclipse update mechanism. The details are provided on the web site.

I cannot say that I’m fully happy with the results that I achieved. I had hoped to get more mileage out of the integration with Scion, but adding all these features through the Eclipse API turned out to be hairier than I expected. However, I do feel I have made useful contributions on which future work can build.

I would like to thank my mentor, Thomas Schilling a.k.a. nominolo, for his guidance and his work on Scion. I would also like to thank Leif Frenzel, without whom EclipseFP wouldn’t have existed in the first place. And finally, thanks to the folks at Google who made GSoC a reality.

For now, I am forced to other business that I’ve been neglecting for far too long. Does that mean that EclipseFP is going to disappear from the radar again? I think not. There is sufficient interest in Haskell IDEs to keep this project going, and somebody will come along and keep improving upon it. Such is the nature of open source. And that somebody… might actually be me.

Update: it isn’t me after all. Less than a week after I wrote this, JP Moresmau chimed in on the mailing list, reporting some bugs, offering to fix them, then continue from there. He’s now taken over development. If you want to try EclipseFP, I recommend his latest version from here!


Build targets

My previous post was three weeks ago. However, I’ve been occupied with other business for a week, and been down with the flu for another; so, in a way, this is still a “weekly update.” I’m actually surprised at how much I got done during this period.

Google Summer of Code is officially over, but my project isn’t. My original project proposal said that I would be adding “Cabal support” to EclipseFP during the second half of the project. Soon after I submitted the proposal, it turned out that I’d been looking at an ancient version of the code base, and that Cabal support was already very much there.

So, essentially, I worked on non-Cabal support instead. That is, being able to compile non-trivial, multi-module programs without the overhead of Cabal. For beginning Haskell programmers, having to deal with just the Haskell source file is less intimidating. It also makes it easier to quickly hack up a program without having to worry about Cabal (maybe adding a Cabal file later). For more advanced functionality, however, the use of Cabal will still be required; it is not my intention to completely replace it.

To get this done, I introduced the notion of build targets. A build target is either an executable file or a library, built from the source code. In the case of an executable, it has a main function. In the case of a library, it has a list of the modules to be included in the library.

The nice thing about build targets is that they provide a subset of Cabal’s functionality. So, if a project does have a Cabal file, the very same user interface can still be used, but instead of writing to the EclipseFP .hsproject file, it writes the build targets as executable/library stanzas to the Cabal file. (Although, currently, automated Cabal file manipulations are broken. They used to be done through Cohatoe, the Java-Haskell bridge, which was removed in favour of Scion.)

Internal representation of the build targets is in place, and they can be stored in the .hsproject file. I am currently working on the GUI for adding, removing and modifying build targets. Even after months of use, the Eclipse API is still daunting, and I keep needing new parts of it, so this progresses slowly. The next step will be to make the builder actually take them into account, but this should be a fairly simple task.

When all this is in place and tested, I will see whether the plug-in can be distributed through the Eclipse update mechanism. Maybe I’ll even roll a Haskell-specific Eclipse distribution that includes the EclipseFP plug-in and its dependencies, to make getting started easier than ever.