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

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.

• Re: Button: A fast, correct... Walter Bright via Digitalmars-d-announce
• Re: Button: A fast, co... Andrei Alexandrescu via Digitalmars-d-announce
• Re: Button: A fast... Jason White via Digitalmars-d-announce
• Re: Button: A ... Andrei Alexandrescu via Digitalmars-d-announce
• Re: Button... Jason White via Digitalmars-d-announce
• Re: B... Atila Neves via Digitalmars-d-announce
• R... Jason White via Digitalmars-d-announce
• R... H. S. Teoh via Digitalmars-d-announce
• R... Jason White via Digitalmars-d-announce
• R... Atila Neves via Digitalmars-d-announce
• R... Fool via Digitalmars-d-announce
• R... H. S. Teoh via Digitalmars-d-announce
• R... Jason White via Digitalmars-d-announce
• R... H. S. Teoh via Digitalmars-d-announce
• R... Jason White via Digitalmars-d-announce
• R... H. S. Teoh via Digitalmars-d-announce
• R... Jason White via Digitalmars-d-announce
• R... Atila Neves via Digitalmars-d-announce
• R... H. S. Teoh via Digitalmars-d-announce