Having a bit if fun on stackoverflow

[Idan Arye]

On Wednesday, 26 June 2013 at 23:40:52 UTC, H. S. Teoh wrote:

> 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.

Whether it needs to be automated to be called a build process is 
a matter of definitions. The important thing is to agree that 
it's bad.


> 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.
>
> ...
>
> 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.

I don't consider having to write 50 commands each time you want 
to build the software that harmful - not because it's good, but 
because it's so bad that no developer will agree to live with it. 
And luckily for most developers - that's a problem they don't 
have to live with, because IDEs can handle it pretty well.

The real problem is with commands that you only have to type now 
and then. For example, let's assume you have a .lex file 
somewhere in your project. Visual Studio does not no how to 
handle it(I think - it has been years since I last touched VS, 
and I didn't do any advanced stuff with it). But VS knows pretty 
well how to handle everything else, and you don't want to start 
learning a build system just for that single .lex file - after 
all, it's just one command, and you don't really need to do it 
every time - after all, you rarely touch it, and the 
auto-generated .yy.c file stays in the file system for the next 
build.

So, you use the shell to call `flex`, and then compile your 
project with VS, and continue coding happily without thinking 
about that .lex file.

A few weeks pass, and you have to change something in the .lex 
file. So you change it, and compile the code, and run the 
project, and nothing changes - because you forgot to call `flex`. 
So you check your code - but everything seems OK. So you do a 
rebuild - because that usually helps in such situations - and VS 
deletes the .exe and all the .obj files, but it doesn't delete 
the .yy.c file - because it's a C source file, so VS assumes it's 
part of the source code - and then VS compiles everything from 
scratch - and again nothing changes!

So, you do what any sane programmer would do - you throw the 
computer out of the window.

When your new computer arrives, you check out the code from the 
repository and try to compile, and this time you get a compile 
error - because you don't have the .yy.c file. Now you finally 
understand that you forgot to call `flex`!

Well, you learned from your mistake so you won't repeat it again, 
so you say to yourself that there is still no point in 
introducing a build system just to handle a single .lex file...


That's why I'm not worried about problems that you can't live 
with. If people can't live with a problem - they will find and 
implement a solution. It's the problems you *can* live with that 
make me worry - because there will always be people who prefer to 
live with the problem than to be bothered with the solution...


> 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.

With that I don't agree - simple projects that only have source 
files can get away with IDE building, even if they have multiple 
source files. I'm talking about zero configuration projects - no 
auto-generated files, no third party libraries - all you have to 
do is create a default project in the IDE, import all the source 
files, and hit F5(or the equivalent shortcut). The moment you 
have to change a single compiler switch - you need a build system.

I myself always use a build system, because I use Vim so I don't 
have IDE building. The only exception is single-source files of 
interpreted languages, where I can use shebangs.