Button: A fast, correct, and elegantly simple build system.

[Jason White via Digitalmars-d-announce]

On Tuesday, 14 June 2016 at 10:47:58 UTC, Fool wrote:
> Switching the compiler version seems to be a valid use case. 
> You might have other means to detect this, though.

If you want to depend on the compiler version, then you can add a 
dependency on the compiler executable. It might be a good idea to 
have Button do this automatically for every command. That is, 
finding the path to the command's executable and making it a 
dependency.

> A possible use case is creating object files first and packing 
> them into a library as a second step. Then single object files 
> are of not much interest anymore. Imagine, you want to 
> distribute a build to several development machines such that 
> their local build environments are convinced that the build is 
> up to date. If object files can be treated as secondary or 
> intermediate targets you can save lots of unnecessary network 
> traffic and storage.

You're right, that is a valid use case. In my day job, we have 
builds that produce 60+ GB of object files. It would be wasteful 
to distribute all that to development machines.

However, I can think of another scenario where it would just as 
well be incorrect behavior: Linking an executable and then 
running tests on it. The executable could then be seen by the 
build system as the "secondary" or "intermediate" output. If it 
gets deleted, I think we'd want it rebuilt.

I'm not sure how Make or Shake implement this without doing it 
incorrectly in certain scenarios. There would need to be a way to 
differentiate between necessary and unnecessary outputs. I'll 
have to think about this more.