Oh no! There's code too!

I've decided to revive an ancient project of mine: the autodiscovering build system. I started working on this around 1995, and used it in several companies. It's kind of sad to see it languish, as I  believe it to be superior to most systems used to date (of course I would)...

For this purpose, I placed a public mercurial repo on bitbucket, at http://hg.fortified-bikesheds.com/cook-autodiscovery/.

On most UNIX boxes, it should be possible to simply clone the repository, then perform the usual

./configure
make
sudo make install

You can then enter the examples subdirectory, and run the "b" (for build) command, installed as part of the system. This should build 4 samples, each representing a common C/C++ project scenario, and pack them up as an RPM.

Big caveat. I'm reviving this after about a 6 year break, so some stuff is likely to break (and yes, I realize that these days, Debians are cooler than RPMs, so maybe I'll add a debian packaging module).

My goal is to get this into a presentable state again, do a little bit of refactoring to expose a better plugin architecture, and then take some big C/C++ project (firefox?) and apply it. This might take a while.

The benefits of getting this done are:

• reliable parallel and incremental builds, even after source tree re-orgs;
• improved error logging by virtue of every construction step having its own log file;
• improved build debugging by having the actual build scripts for every step explicitly available;
• fine grained build configuration with exact tracing of the origins of every setting;
• simplicity for the developer: "drop code here".

Some drawbacks exist, of course:

• No IDE support - it's conceivable to add a project file generator to this, or leverage existing project file generators. Of course, once you add a project file generator, the benefits of the incremental builds go away...
• Modern C/C++ toolchains tend to choke over the link step, rendering the benefit of incremental parallel builds less interesting
• Expects a "traditional" large source tree. In other posts, I've been arguing that many small source trees, each generating archives or artifacts might be a better way to go.

So, lots of challenges ahead!