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.