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

[Jason White via Digitalmars-d-announce]

On Friday, 17 June 2016 at 06:18:28 UTC, H. S. Teoh wrote:
> 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.

I couldn't agree more! Correctness is by far the most important 
feature of a build system. Second to that is probably being able 
to make sense of what is happening.

I have the same problems as you in my day job, but magnified. 
Some builds take 3+ hours, some nearly 24 hours, and none of the 
developers can run full builds themselves because the build 
process is so long and complicated. Turn-around time to test 
changes is abysmal and everyone is probably orders of magnitude 
more unproductive because of it. All of this because we can't 
trust Make or Visual Studio to do incremental builds correctly.

I hope to change that with Button.