Saturday, June 25, 2011
Now, the GhcOptions record has become a direct representation of the command line options; every flag used in building Cabal packages can be adjusted individually. Creating the options for a particular mode and stage consists of glueing together (through mappend) a long list of GhcOptions pieces. There's pieces for (among others) build options, c options and verbosity options, allowing much more fine grained control of the options given to GHC.
Wednesday, June 15, 2011
Starting GHCi with Cabal is fairly easy, as the interpreter takes most of the same arguments we've been feeding GHC. But reloading it is a little more difficult. Admittedly, there are a number of things we don't have to do when reloading:
- All the options given to the interpreter initially seem to come along for the ride with each :reload command, so rendering GHC command line options isn't necessary.
- Preparing the build directory and auto-generated files already took place when the interpreter was started, so that stuff isn't required for a reload.
In fact, there are only really two things that need doing. First, there's preprocessing. This is a high level operation not specific to a compiler. At the same time, there's C sources, a step in building restricted to GHC.
To define these macros, I think I'll need to modify GHCi to take a custom .ghci file. I can't just sneakily add to the user one, and piping in the commands through cat or something would look ugly. As it is, I think the best approach is to add an option for an extra .ghci file. Cabal would write its set of macros to shadow default commands to some place in the dist directory, telling GHCi about the the file.
Tuesday, June 14, 2011
- Call whatever programs needed for preparing the package for building
- Un-define the command so that the default behavior returns
- Call the default command
- Respecify the custom implementation
- Redefine the command