> but my point is that it could do more, including checks.
Could you explain more how you see this working?
For example: the build system is running a build step. It has determined the inputs and the outputs for that build step. It is going to execute a subprocess for that build step (say, GCC). It wants to ensure that GCC doesn't accidentally depend on files other than thaie that the build system knows about. How can that functionality be implemented with checks in the build system interpreter?
I suppose it could run the process with something strace-like and monitor which files it accesses but isn't that just a way of implementing a sandbox? I'm not sure what you mean exactly.
The best way to do this is best described in the thesis that Eelco Dolstra wrote describing Nix. I suggest you read that.
tl;dr: Clear the environment, know where all of the system headers are, control the build environment of the dependencies. Basically, knowing dependencies means controlling them.
But to expand on that, an interpreter could do some basic checking like:
* Does the command reference a path that the build system doesn't know about?
* Does the build system know where the executable is for the command, and is it well-known?
Things like that.
It won't be perfect, but it would be better. And it can get better with time.
Could you explain more how you see this working?
For example: the build system is running a build step. It has determined the inputs and the outputs for that build step. It is going to execute a subprocess for that build step (say, GCC). It wants to ensure that GCC doesn't accidentally depend on files other than thaie that the build system knows about. How can that functionality be implemented with checks in the build system interpreter?
I suppose it could run the process with something strace-like and monitor which files it accesses but isn't that just a way of implementing a sandbox? I'm not sure what you mean exactly.