ralphbsz, thanks for your detailed response!
One can think of a build system as consisting of a set of tasks: 1) keeping track of dependencies 2) triggering specific target builds based on what dependencies change, 3) scheduling the affected target builds, 4) invoking a command to do the actual build of a target (as well as discovering dependencies), and 5) processing specification of all this in some build specific language (BSL).
Seems that most of the build system related complaints are usually about its BSL providing insufficient flexibility or being too complicated, which is often made worse by a bad BSL design. There is inherent complexity when
interdependent programs in more than one language have to be built + when you have to support more than one processor arch. or OS or compiler or OS, compiler & library versions. On top of that we don't want to explicitly specify everything for each of the source files so we need a way to specify more generic
rules. And ideally we want a 100%
reproducible builds.
As an individual developer you just want to build a small number of programs or libraries (if not just one) and you don't care about multiple platforms or compilers but if your s/w is part of a larger set, someone has to worry about these things. Just in FreeBSD, /usr/share/mk contains over 12K lines of *.mk files, not counting the 2200+ lines of *.mk in /sys/conf! So there is considerable complexity behind a simple Makefile which can be as small as
PROG=foo
.include <bsd.prog.mk>
Back to bazel. I think it does a pretty good job of all the tasks listed above but falls short on BSL in terms of usability. IMHO of co
one can do considerably better in place of its "skylark" BSL in terms of usability & making things less magic. Search for "bazel tutorial" on youtube and you will find many long videos with titles like "Introduction to Bazel to build ..."!
I suspect one can define a simpler, less magic BSL that can do bulk of the work that bazel does.... But really when the problem is inherently complex, all you can do is push around this complexity.
Interested people may want to check out
Gilad Bracha's talk on ShapeRank -- around 5:30 he talks about how one can treat the build process as a
reactive stream!