examples

d. There are a bunch of 'meta' tools for this, bazel, pants, buck, gradle, etc. Professionally I have only seen bazel used. I suspect its less to do with the tools themselves, but more to do with the ecosystem. With that being said, bazel does seem to solve most of the sharp edges we had with our ad-hoc/no tooling, but it comes at a cost. Bazel is not trivial, and won't allow you to do some things that the underlying toolchain might have been okay with. So that may leave you making code changes to fit inside bazels constraints. Bazel tooling also isn't equally mature across all languages. The go tooling is pretty mature, and there are great generators that 'make things work', the situation for frontend is less mature, but getting better. It will add additional friction that webdevs might not love. At the end of the day though, I would choose to use something like bazel (or one of the alternates), and the friction it brings over not having it. Example bazel frontend. https://github.com/bazelbuild/examples/tree/main/frontend/ne...

s.chunks, outputs = [ctx.outputs.out], arguments = args, progress_message = "Merging into %s" % ctx.outputs.out.short_path, executable = ctx.executable.merge_tool, ) concat = rule( implementation = _impl, attrs = { "chunks": attr.label_list(allow_files = True), "out": attr.output(mandatory = True), "merge_tool": attr.label( executable = True, cfg = "exec", allow_files = True, default = Label("//actions_run:merge"), ), }, ) This is, admittedly, not easy to follow at first glance. Concat defines a "rule" (just like cc_binary) that takes three arguments: "chunks", "out", and "merge_tool" (and "name", because every target needs a name). Targets of this form have metadata, they have input and output files that are known and can be queried as part of the dag. Other types of rules can be tagged as test or executable, so that `blaze test` and `blaze run` can autodiscover test and executable targets. This metadata can also be used by other rules[2], so that a lot of static analysis can be done as a part of the dag creation, without even building the binary. To give an example, a rule like does_not_depend_on( name = "check_deps", src = ":opensource_thing", forbidden_deps = [ "//super/secret:sauce", ] ) can be built and implemented natively within bazel by analyzing the dependency graph, so this test could actually run and fail before any code is compiled (in practice there are lots of more useful, although less straightforward to explain, uses for this kind of feature). Potentially, one could create shadow rules that do all of these things, but you'd need to do very, very silly things like, off the top of my head, creating a shadow filesystem that keeps a file-per-make-target that can be used to query for dependency information (make suggests something similar for per-file dependencies[3], but bazel allows for much more complex querying). That's what I mean by "object-oriented". Targets in bazel and similar are more than just an executable statement with file dependencies. They're complex, user-defined structs. This object-oriented nature is also what allows querying (blaze query/cquery/aquery), which are often quite useful for various sort of things like dead or unusued code detection or refactoring (you can reverse dependency query a library that defines an API, see all direct users and then be sure that they have all migrated to a new version). My personal favorite from some work I did over the past year or so was is `query --output=build record_rule_instantiation_callstack`, which provides a stacktrace of any intermediate startlark macros. Very useful when tracking down macros that conditionally set flags, but you don't know why, and a level of introspection, transparency, and debugability that just isn't feasible in make. That's what I mean by object-oriented vs. text oriented. Bazel has structs with metadata and abstractions and functions that can be composed along and provide shared, well known interfaces. Make has text substitution and files. While a sufficiently motivated individual could probably come up with something in make that approximates many of the features bazel natively provides, I'm confident they couldn't provide all of them, and I'm confident it wouldn't be pretty or ergonomic. [0]: https://docs.bazel.build/versions/master/skylark/rules.html [1]: https://github.com/bazelbuild/examples/blob/master/rules/act... [2]: https://docs.bazel.build/versions/master/skylark/aspects.htm... [3]: https://www.gnu.org/software/make/manual/html_node/Automatic...