Self Build System part 2

Back in the early 90s when I first encountered Self, my reaction was one of "my god I can move stuff around!". Being able to just move a slot from one object to another, for me, solved the very obvious problem of cut and paste programming. Our linear source files make any sort of reorganization a chore, and collapsing editors make terribly poor use of lateral space. If you are like me, you probably want to treat block of code like blocks of Lego. Self got much closer to that.

When I started working on Phos, my "ad hoc" JavaScript programming environment, I really wanted to capture that sense. Drag and drop, direct manipulation, and remove syntax that was only there to make linear source files easier to parse. (as a side note most of my qualms with coffeescript fall in that category or the everything should be a message send one). I then started playing around with editing my C projects in the same way. In stead of source files in version control, just have a database of functions, all named, numbered, and annotated so that you could pick and choose versions at compile time. I wrote some simple tools to grab a dependency graph and walk it to pluck out and build multiple versions of the same program. This made building and testing multiple versions of a project really easy. Rather than guess which build is the best, it could be tested empirically.

My thinking about the Self build system runs along those lines. Each functional module of code should be well named, via a URI, and be swappable for any other version of that code which maintains the same API. If two or more developers have functional implementations, a build configuration can be used to simply address which one you want to include. The other bit of this is that unlike distribution via GIT, the assembly of the source base can be delayed until the last possible moment, and in some cases delayed until the feature is needed. You could think of the build system as a proxy stub which could on demand load and build new built-in functionality by dynamically fetching and loading modules. You can do this in Perl by hacking CPAN I to your autoloader, but lazy loading features you may never use seems even smarter.

When trying to build distributed systems, one of the hardest tasks is validating that each component in the system has all of it's dependencies met on every node where the code may run. Having a node segfault repeatably because the wrong version of a shared library was installed can become an exercise in pure frustration. This gets progressively more complex as the system grows in application space. The more teams and requirements placed upon a shared environment leads to lower stability and greater potential for disastrous change. Building a build system that can intelligently discover a solution adapted to each specific environment may provide an organic method for building systems which adapt rather than fail.

But ultimately, the goal of my build system is to break the build down into the smallest sensible chunks and dynamically assemble a functional system from those bits. Until a project like Klien is complete, the reality is that Self will need to work with a build system rooted in anachronistic practices and traditions rooted in yesteryear. But from the standpoint of opening up the old code base to new eyes and the possibility of change, a networked boostraping build system make make a difference.