At best, you can cheat with system() function
but then all the dependency checking is lost.

Make systems are all conceptually wrong.
There a huge number of projects to replace
Make (and autoconf et al) and not a single
one I've seen recognizes that the fundamental
design is flawed .. instead they all try to
copy the make idea.

First observe that building a system
is a process where it is not always
possible to determine the full sequence
of commands in advance. Sometimes,
you have to perform some action before
you can decide what to do next.

Example: you cannot build interscript
packaged sources or a tarball directly,
you have to extract the contents first.

Example: the rules for building a package
may have to be generated or extracted
from the package.

Next observe that the linear dependency
checking is naive. First, what some
target depends on can be conditional:
obviously true for C :-)

But it is much worse. A target can
depend on itself. Interscript assumes that.
An example is a Latex build, which depends
on auxilliary files generated by the build
[Ocamldoc output can take 4 passes to fixate
for example].

This leads to the first novel idea. Fixpoints.
Interscript is based on that idea.

With fixpoints, you dont CARE about dependencies.
What you do is repeatedly execute some process
until the defined outputs are stable. The inputs
do not need to be known.

Now we backstep. We try to *predict* whether
the outputs will be the same this run as last.
If we can -- and we have to be *sure* -- we
can terminate one cycle earlier.

This is dependency checking with a new twist:
its optional. :-)

Well, I will jump ahead now. A build system
does NOT have targets. That's a bad idea too.

A build systems has processes and files.
Lets call the processes ARROWS and the files OBJECTS.

Oh. That's a category. We allow of course,
products of files (multiple outputs and inputs)
and sums of files (choose one of several).
[And of course we'd better make it cartesian
closed and allow processes to be files ..
called scripts .. :]

The control system allows you to 'click' on
an arrow to execute the process. This is manual
running. It also allows to to click on a object
to run all the processes required to produce
the object. By using a caching concept, some
process can be elided as an optimisation.

For example .c -cc--> .o -link--> exe, we can
use the cached .o instead of running cc on the
.c provided the .c is older.

BTW: I have *built* this system, including
a graphic interface which allowed construction
of the build category.

I needed this much power. Make is a total joke.
What I was doing was writing a book, literate
programmed of course, and needed to generate
a LOT of different documents -- I had to build
code, test it, capture the output, typeset
the book, build indices, contents ...

In a *real* build system, you do NOT want
to make everything from scratch everytime.
Sometime you're happy using old data,
at least for a while.

Anyhow .. a lot of new ideas for a build
system are here. Just copying the make concept
is not going to solve any problems .. its going
to make things much WORSE by having yet another
inadequate tool -- which of course the poor client
will have to build, making the tool chain even longer.
[Trying to replace Make destroyed Boost IMHO]