Having a bit if fun on stackoverflow

[H. S. Teoh]

On Thu, Jun 27, 2013 at 01:07:19AM +0200, Idan Arye wrote:
> On Wednesday, 26 June 2013 at 21:28:08 UTC, H. S. Teoh wrote:
[...]
> >So we use makefiles... which are a royal PITA, but at least they give
> >you a semblance of reproducibility (fresh version control checkout,
> >run ./configure && make, and it produces a usable product at the
> >end).  I have a lot of gripes about makefiles and would never use
> >such broken decrepit technology in my own projects, but they are
> >nevertheless better on the reproducibility front than some IDE "build
> >process" that nobody knows how to replicate after the key developer
> >leaves the company.
> 
> Add that to the long, long list of crappy tools that became the
> standard...

Tell me about it. Makefiles have so many dark nasty corners that any
non-trivial application will have an unreadable, unmaintainable
makefile. Not to mention reliance on timestamps (very unreliable), and
inability to parallel-build without specifically crafting the makefile
to support that, etc..


[...]
> My point is that bad practices lead to more bad practices:
> 
> Letting your IDE automatically handle the details of the building
> process is bad.

+1.


> As your project become more complicated, and you need to use third
> party libraries and auto-generated files, then the bad practice of
> using F5 as your build process forces you to other bad practices -
> downloading those third libraries and using those generation tools
> manually.

Stop right there. As soon as "manual" enters the picture, you no longer
have a build process. You may have a *caricature* of a build process,
but it's no build process at all. I don't care if it's hitting F5 or
running make, if I cannot (check out the code from version control /
download and unpack the source tarball) and *automatically* recreate the
entire distribution binary by running a (script / makefile / whatever),
then it's not a build process.

To me, a build process means it's possible to write a script that, given
just the pure source tree, can recreate, without any human intervention,
the entire binary blob that you give your customers. Anything short of
that does not qualify as a build process.

A hand-written document that explains the 50+1 gcc/dmd/whatever commands
you must type at the command prompt to build the software does not
qualify as a build system.


> Now, what if someone called sick for a couple of weeks? Now he has to
> scan through the mailing list to collect all the mails about changes
> to the configuration process. Alternatively, he could scan the
> configuration instruction document and compare it to what he has
> already done - assuming he remembers he ran tool A, but not tool B,
> and he ran tool C but with different flags than what's specified in
> the up-to-date instructions. Another option is to use the SCM's diff -
> but that's still a pain, and frankly - I don't think people that can't
> use a build system are smart enough to use diff...

If you have to manually type anything more than "gcc -o prog prog.c" to
build a project (and that includes adding compile flags), that project
has already failed.


> So, the best thing to do is to check in those auto-generated files and
> those external libraries, and let the SCM keep everyone synced.
> That's a crappy solution - but if you don't use a build system, it's
> your best solution. And when bad practice becomes your best solution -
> you know you have a problem.

If you don't have a build system, your project is already doomed.
Nevermind auto-generated files, external libraries, or SCMs, those are
just nails in the coffin.  Any project that spans more than a single
source file (and I don't mean just code -- that includes data,
autogenerated files, whatever inputs are required to create the final
product) *needs* a build system.


T

-- 
The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners... -- Slashdotter