Information is Beautiful did a visualization a couple years ago that attempted to answer this exact question. It hasn't been updated since end of 2020 but perhaps this will still be useful to some readers here:
But unless you're already using Bazel, it's impractical to suggest "just use Bazel to distribute your builds" as doing so requires that you first migrate your build to Bazel. distcc, as noted, can be applied to an existing build regardless of the build tool used.
So, you’re saying that it’s impractical to switch build systems, and that it’s inappropriate to suggest alternative build systems?
I think that if you’re reading a suggestion to “just use X” on Hacker News, the sensible thing to do is to evaluate the suggestion for your own. You don’t need to put a long list of caveats in front of every software recommendation. If your problem is, “My builds are slow, I want distributed builds,” then you should probably at least consider the two most popular solutions to that problem, which are Bazel and Distcc. Both with their drawbacks.
I found that the LPS lighting in San Jose was very close in color to yellow traffic signals, which made it sometimes confusing (and therefore more dangerous) to drive there after dark.
Electric Make has had sandboxing since 2002, no conversion from your familiar make-based builds to a new shiny build tool required, and it can make on-the-fly corrections to execution order if that sandboxing reveals that incomplete dependency specifications caused something to run in the wrong order (relative to a strictly serial build).
"Sandboxing" in a build tool cannot be claimed as Bazel's innovation.
If you're looking to serialize parallel build logs without changing to an entirely new build tool:
1. Electric Make, a high-performance reimplementation of GNU make and ninja, has properly serialized build output logs since it was introduced in 2002 (https://electric-cloud.com/products/electricaccelerator) (disclaimer: I'm the chief architect for ElectricAccelerator, of which Electric Make is a component).
2. I published a technique on CM Crossroads you could use with GNU make 3.81 to descramble parallel build logs in 2009. The article has moved around since then but these days it seems to be found at https://www.cmcrossroads.com/article/descrambling-parallel-b....
That is a good article, but it doesn’t seem to address several of the concerns raised in my redo article. In particular, it looks like the final output is still in a nondeterministic order, it doesn’t print output from a given target incrementally while it runs, and you can’t query the log retroactively to look for clues in a very big run.
It’s a big advantage to not have to change tools, of course. Although redo happily interoperates with makefiles (which is how the buildroot patch works) so there’s no need to convert everything to get most of the advantages.
Correct, both the technique described in that article and the feature that eventually wound up in GNU make only disentangle output from concurrently executing build processes. With significantly more work GNU make could probably be made to enforce a deterministic order.
However, Electric Make does emit the output in a deterministic order, in fact in exactly the same order as the build would have produced had it run serially. In practice the delayed output is not such a big deal -- people just don't really seem to care that much, when the build overall finishes 20x - 30x faster than it used to. Electric Make also generates an annotated build log, essentially an XML-marked-up version of the log, which contains a tremendous amount of additional information about the build and vastly simplifies debugging, actually.
Hey, Electric Make looks really cool - I ran into it while I was tinkering with https://github.com/dan-v/rattlesnakeos-stack. I also have done a fair few builds in buildroot. It wasn't clear to me at all if you offer anything for open source work / hobbyists - I'd love to try it out.
Nothing in the linked 14-page window replacement guide has anything at all to do with safety in general or windows falling onto people. It is entirely to do with preserving the "historic character" of buildings. I don't think you can reasonably equate that to the regulations governing the design of caps on baby food.
Unfortunately very many people casually lump a huge range of maladies under the umbrella of "RSI" and treat them as if they all have the same root cause and the same remedy. Wrist/arm pain could be carpal-tunnel syndrome, or it could be tendonitis, or it could be any of a bunch of other things all of which are technically "RSI". For some, strength training can certainly help; for others, as in your case, it may do more harm than help.
I totally agree. I never actually went to a Dr to get my wrist pain looked into so I don't know 100% that it was RSI. I just kind of assumed that it was based on RSI being an occupational hazard for many tech folks.
Changing my keyboard got rid of the immediate pain I had been experiencing for months. I started weight lifting at around the same time. The only reason I attribute lifting as being part of the solution is that I went back to typing on my laptop again after 6 months.
I now do quite a lot of typing on my laptop (90% of the software I write) and I no longer have any pain in my wrists.
This advise is probably not for everyone, I just offer it up as an interesting anecdote. If you have persistant wrist pain, its probably best to go see a specialist.
That's true if you limit yourself to, say, GNU make -- but there are GNU-make-compatible alternatives like Electric Make, part of ElectricAccelerator (http://electric-cloud.com/products/electricaccelerator), that add features like ledger, to trigger rebuilds when compiler flags change; filesystem monitoring for truly accurate dependency detection; and parse avoidance, to avoid reparsing the makefile on every run; as well as a long list of other enhancements.
Disclaimer: I'm the author of TFA and Chief Architect for Electric Make.
I think when you say "make Android builds faster", you mean "make Android application builds faster" -- as opposed to making Android operating system builds faster. Those are two very different things, and for the uninitiated the casual use of language here is confusing. The Android operating system has never been built with ant, but historically was built with make until around Android N when that team started migrating to ninja-based builds instead.
I got confused by the exact same language 5 years ago when one of the Apache Groovy project managers (before it joined the ASF) started repeatedly saying "Google have now chosen Groovy and Gradle for building Android." I didn't know if they meant building Android at Google, or as the default build system shipping with their (then) new Android Studio tool.
https://www.informationisbeautiful.net/visualizations/snake-...