WARNING. This is an unstable API use at your own risk.
- Treat build operations as pure functions that affect the file system
and memoize their results.
- Parallelize build operations by synchronizing on the files they
read and writes.
- Tight control over tool lookup and build environment.
Concepts dropped and to be seen how we can recover them at a higher level:
- Build aims for cross compilation (build/host OS distinction). This
should be capturable as two separate
- Build units (named sets of build operation with metadata)
- Build operation synchronisation, only files for now, we had
unit-level. Did introduce
B00.Memo.Fut for odig.
- Build configuration.
- Build unit/config definition localisation (multiple B0.ml files)
- Build directory structuring and forced clean builds
- Build metadata, unit and file level, packages.
- The concept of response file in
B00.Tool should likely appear at
B00.Op.spawn level aswell so that we can simply have the sequence
B00.Op.t value for a potential build log (otherwise
becomes the line with the response file which is not meanigfull)
- Operations, b0 also had file deletion and copy maybe add them
aswell. Copy can be expressed in terms of read/write but maybe
better to have as a primitive for concurency. Delete doesn't
fit well in the "file ready" model, but could be useful for
- Spawn redirection should maybe create the paths of the file
they write to.
a40f438 — homepage
Build operations guards.
Build operation executors.
Command line tools.