Having a bit if fun on stackoverflow

Idan Arye GenericNPC at gmail.com
Wed Jun 26 16:07:19 PDT 2013


On Wednesday, 26 June 2013 at 21:28:08 UTC, H. S. Teoh wrote:
> On Wed, Jun 26, 2013 at 10:23:21PM +0200, Idan Arye wrote:
>> I guess that depends whether or not F5 is your build process
>> (http://www.codinghorror.com/blog/2007/10/the-f5-key-is-not-a-build-process.html).
>
> What's F5?

In Eclipse, F5 is the key to compile your project and run it in 
debug mode. The link I've given is to a blog entry by Jeff 
Atwood, where he explains why it's so bad to use F5 as your 
"build process" - that is, rely on the IDE to build your project.

Ofcourse, nothing is wrong with the F5 key itself. In my Vim 
settings I've mapped F5 to launch a proper build system.

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

> That's why I said, auto-generated files should NOT be included 
> in
> version control. Unfortunately it's still being done here at my 
> work,
> and every now and then we have to deal with silly spurious merge
> conflicts in addition to subtle ABI inconsistency bugs like I 
> described
> above.

My point is that bad practices lead to more bad practices:

Letting your IDE automatically handle the details of the building 
process is bad.

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. Even if you document what you did - 
which is far better than *not* documenting it - it's still a bad 
practice, since configuring a build system to do those things is 
a bit easier than explaining in English what needs to be done, 
and invoking the build system is much easier than following the 
instructions manually.

If you need to use SCM things get even worse. Other people will 
need to build the project, so they will need those libraries and 
auto-generated files. If you used a build system and a dependency 
manager, that would be easy - but you didn't, so now the other 
guys need to follow your documented instructions 
manually(assuming there are documented instructions) - and it 
becomes very cumbersome.

And it gets worse - if someone changes something in that textual 
"build system" - that is, does something and writes it in the 
documentation - everyone else need to do it. But people don't 
reread the how-to-configure document every time they do a 
checkout - so now you need to email everybody about the change.

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

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.


More information about the Digitalmars-d mailing list