Along with sketching out an explicit group development process, we discussed several other aspects of our project's organization. As these were relatively straight-forward things, I've grouped them all here.
A 'wrapper' is what makes it possible to run the Transterpreter on a new platform. That is, cross-compiling the interpreter for a new architecture is boring and easy. Connecting up the language to the hardware (or underlying operating system) is the interesting bit, and the wrapper is where we do that work.
Up until now, we have typically done wrapper development in branches. However, this is difficult, as it means each wrapper developer must constantly be merging the trunk back into their branch. This is silly, as most of our wrappers we want to remain current, and take advantage of any improvements in the trunk.
So, moving forward, we're going to try and keep wrapper development in the trunk. Because wrappers are mutually exclusive, we don't have to worry about one adversely influencing the other, and it will make it easier for us to make sure that changes that help one branch doesn't hurt another (eg. using buildbot and cross compilers).
This requires us to be a bit more vigilant about...
Up until now, we've been rather lazy about tagging. As a group, we need to start tagging more often. This might be by deciding on features that should go into milestones, or perhaps through an ad-hoc democratic process, where someone suggests that we tag, and the group agrees (or disagrees) that it is a good time to do so.
This is an area that requires more discussion, but it is clear that the project could do with more versioning and tagging, providing snapshots of known good/stable points.
Adam has been doing a lot of work at making libraries for occam-pi cross-runtime buildable. By this, I mean that we have a situation where we have two runtimes (CCSP and the Transterpreter), each which are capable of different things. For example, the interpreter will always be smaller, and therefore more portable to more (embedded) platforms. Unfortunately, if I had developed a C library with occam-pi bindings, it was virtually impossible to use it from both the Transterpreter and the CCSP (KRoC) runtime.
Adam's work has brought us into a world where we can easily build such libraries for either runtime from the same source with minimal effort. This is excellent, and we'll be converting all of our libraries to use this new build system over time. Which, brings me to the last bit...
Some time ago, I explored the use of Scons as a build system. It represents a spike, and can build the Transterpreter for Linux, Mac (PPC and Intel), the MSP430, and Windows.
However, it's a bit ugly. It represents my first time working with Scons, and it could be better. Also, we discovered that mingw provides an environment that lets us easily build everything using our Autotools-based environment. So, whereas we thought the Scons build would improve things across the board, it's not clear that it's a 100% necessary improvement.
Either way, we're going to bring Scons into the trunk, and play with it. Because it is completely orthogonal to the Autoconf/Automake build system, it can't hurt. However, we're going to be looking at this closely over the next few months, as one of them has to go, and we definitely want our build system to be cleaner/better organized/simplified greatly. If that means using Scons, great. If it means revamping our existing system, great.
Those are reasonably straight-forward changes coming down the pipe; as a side effect of these things, we'll likely do some branch cleanup and repos reorganization. As the time comes for these things, they'll be discussed on the development list.
The last thing I'll talk about is a project mission statement and project goals. That'll come later this week.