Volution Build System v2

Goals

Composable builds

As it is really common today for a software product to embed other libraries or even applications within its source code -- maybe because they need a newer version than available on the target systems, or maybe the library is not available everywhere -- it is required that the build process of the dependencies to be integrable with that of the project's.

This is usually realized by resorting to "recursive makes", but it is inefficient, error prone, and it gives a bad feeling.

Examples of this happening in real life:

• most complex Erlang applications: Riak, CouchDB;

• NodeJS itself;

Reusable build artifacts

There are cases where the same project is used as a build dependency for other ones. Thus instead of rebuilding the same project multiple times it would be nice to cache the intermediate results and reuse them. These results could be a snapshot of the build directory.

As could we should steal the idea from #Maven of artifacts, but not transform the tool into a package manager. At most these would be similar with *-devel libraries in some distributions.

Design

Sketch:

• the dependency graph and status should be handled by #Ninja;

• the recipe execution should be delegated to a specialized tool;

• the recipe commands should be stored in a #cdb database;

References

• Recursive Make Considered Harmful;

Links

• build systems:

  • Ninja;

  • Tup;

  • Gyp;

  • Rebar;

  • Maven;

  • Buildout;

• libraries:

  • cdb;

  • tinycdb;