Button: A fast, correct, and elegantly simple build system.

[H. S. Teoh via Digitalmars-d-announce]

On Fri, Jun 17, 2016 at 05:41:30AM +0000, Jason White via Digitalmars-d-announce wrote:
[...]
> Where Make gets slow is when checking for changes on a ton of files. I
> haven't tested it, but I'm sure Button is faster than Make in this
> case because it checks for changed files using multiple threads. Using
> the file system watcher can also bring this down to a near-zero time.

IMO using the file system watcher is the way to go. It's the only way to
beat the O(n) pause at the beginning of a build as the build system
scans for what has changed.


> Speed is not the only virtue of a build system. A build system can be
> amazeballs fast, but if you can't rely on it doing incremental builds
> correctly in production, then you're probably doing full builds every
> single time. Being easy to use and robust is also pretty important.
[...]

For me, correctness is far more important than speed. Mostly because at
my day job, we have a Make-based build system and because of Make's
weaknesses, countless hours, sometimes even days, have been wasted
running `make clean; make` just so we can "be sure".  Actually, it's
worse than that; the "official" way to build it is:

	svn diff > /tmp/diff
	\rm -rf old_checkout
	mkdir new_checkout
	cd new_checkout
	svn co http://svnserver/path/to/project
	patch -p0 </tmp/diff
	make

because we have been bitten before by `make clean` not *really* cleaning
*everything*, and so `make clean; make` was actually producing a corrupt
image, whereas checking out a fresh new workspace produces the correct
image.

Far too much time has been wasted "debugging" bugs that weren't really
there, just because Make cannot be trusted to produce the correct
results. Or heisenbugs that disappear when you rebuild from scratch.
Unfortunately, due to the size of our system, a fresh svn checkout on a
busy day means 15-20 mins (due to everybody on the local network trying
to do fresh checkouts!), then make takes about 30-45 mins to build
everything.  When your changeset touches Makefiles, this could mean a 1
hour turnaround for every edit-compile-test cycle, which is ridiculously
unproductive.

Such unworkable turnaround times, of course, causes people to be lazy
and just run tests on incremental builds (of unknown correctness), which
results in people checking in changesets that are actually wrong but
just happen to work when they were testing on an incremental build
(thanks to Make picking up stray old copies of obsolete libraries or
object files or other such detritus). Which means *everybody*'s
workspace breaks after running `svn update`. And of course, nobody is
sure whether it broke because of their own changes, or because somebody
checked in a bad changeset; so it's `make clean; make` time just to "be
sure". That's n times how many man-hours (for n = number of people on
the team) straight down the drain, where had the build system actually
been reliable, only the person responsible would have to spend a few
extra hours to fix the problem.

Make proponents don't seem to realize how a seemingly not-very-important
feature as build correctness actually adds up to a huge cost in terms of
employee productivity, i.e., wasted hours, AKA wasted employee wages for
the time spent watching `make clean; make` run.


T

-- 
It is of the new things that men tire --- of fashions and proposals and improvements and change. It is the old things that startle and intoxicate. It is the old things that are young. -- G.K. Chesterton