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.
