[throwaway894345]

I agree with your point, but make solves the problem rather poorly. Besides the poor UX, it only knows the thing it built most recently, as opposed to maintaining a cache of things it has _ever_ built. And since it doesn't have a cache, it definitely doesn't have a distributed cache, although you could conceivably try to shoehorn NFS or something similar. Lastly, it's not reproducible. It's not going to fail a build if you accidentally let it depend on a file that isn't a formally specified dependency. These are all important concerns, especially for a CI environment.

Something like Bazel theoretically solves this problem, but it's poorly documented and non-trivial to use or operate. Other Bazel/Blaze derivatives are worse with respect to usage/operation/correctness. Nix improves on correctness but is even harder to use/operate. There's a lot of room for improvement in this space.

[Foxboron]

I agree with the observation. But the alternatives are grossly over-engineered or a case study in NIH. I'm sticking with Makefiles until someone can present something better.

>Something like Bazel theoretically solves this problem, but it's poorly documented and non-trivial to use or operate. Other Bazel/Blaze derivatives are worse with respect to usage/operation/correctness.

I have night terrors from listening to two of our packagers fighting against bazel, tensorflow and 10 hour compile times.

>Nix improves on correctness but is even harder to use/operate. There's a lot of room for improvement in this space.

I don't think Nix improves anything when you are stuck writing a weird javascript derivative. This comes from a packager writing bash for a living.

[shantly]

Maybe I'm unusual, but I avoid Java-based tools (like Bazel) because my Java environment often seems to be broken for any given piece of Java software, for one reason or another, and I don't want to add "make sure my Java environment is OK for all the Java tools I'm using" to the getting-started steps for any non-Java projects I'm on.

And yes, I mean the JVM, not the Java build tools. It's one of the reasons I go "ugh" when I realize I'm gonna have to run something written for the JVM. There's a decent chance I'll lose time configuring it to get it to work.

[throwaway894345]

> I agree with the observation. But the alternatives are grossly over-engineered or a case study in NIH. I'm sticking with Makefiles until someone can present something better.

I agree that they are complex beasts, but that complexity is incidental, not essential (some might argue "a lack of engineering" rather than "overengineered"). The documentation for these tools is also pretty atrocious on average. However, I don't think they're NIH insofar as their direct ancestor (Blaze) was never publicly available and Bazel didn't exist when those original Googler pilgrims brought their build-system ideas to Facebook, Twitter, Foursquare, etc. But nevertheless, there are half a dozen shitty tools instead of one decent tool. Worse, they're pretty much all designed for use in large organizations' monorepos--organizations who can employ people who are specialists in operating/maintaining these tools.

> I don't think Nix improves anything when you are stuck writing a weird javascript derivative. This comes from a packager writing bash for a living.

The improvements are certainly not uniformly distributed, nor are they sufficient to really justify its mainstream use, IMHO. :)