|
|
|
|
|
|
by trasz
1431 days ago
|
|
|
That is an argument from tradition - which you yourself have brought up, calling Bazel a "standard way". >The value of bazel is never having to run make clean because artifacts aren't correctly being built from cache. You can get that with make(1) too, check out FreeBSD's META_MODE for one example. And it didn't require reinventing the wheel. |
|
|
I didn't do any such thing. My point is simply that make and bazel are similarly "nonstandard single use pseudo languages". In many ways, bazel is superior to make from a language perspective (it resembles other languages more closely, being a dialect of python, and avoids the loadbearing tab issue), so I think I could make the argument that bazel is in many ways less nonstandard, but make is certainly more common than bazel, so it could go either way.
> You can get that with make(1) too, check out FreeBSD's META_MODE for one example.
This suffers from the same issues that natural make does (notably the whole mtime thing). See https://apenwarr.ca/log/20181113 for a much better explanation than I can provide as to why make's entire model of "change" is irreparably broken, and why hash (+sandbox!) based approaches (which bazel and redo and nix and cargo and nearly every other modern build tool use) are far superior.
> And it didn't require reinventing the wheel.
You call inventing a new syscall to not-even-fully fix a limitation of the tool not reinventing the wheel? Like I guess its not, it's just like building a weird grand shrine around the broken wheel. It's far worse. I don't want to need to change my operating system to have make work better, but still worse than the alternatives. That's simply not a compelling argument.