1

We've all heard it - "try a clean build and see if it works". Oftentimes weird run-time errors will disappear after a rebuild. This has made me think - properly tracking dependencies is the job of a build system.

Are such runtime errors by definition bugs in a build system - whether it is make, or msbuild, or whichever. Or put another way, if a clean build and a normal build yield different results, is that by definition a bug in the build system?

Edit: I am assuming the build environment is sane - meaning that when files are updated, their "last modified" timestamp becomes newer (instead of an older timestamp or the same). In fact, all version control systems that I know of follow that rule because otherwise they would break build systems like Make that rely on the timestamps to track which files need to be updated.

Community
  • 1
  • 1
sashoalm
  • 75,001
  • 122
  • 434
  • 781
  • Let's say there's a problem with your system. The problem is fixed by rolling back one of the source modules. You do a regular build. It sees that the time stamp of the compiled module is after the time stamp of the source module, so it doesn't recompile that module. You run the built system and it still has the problem. You run a clean build, and every module is built. Now the problem is fixed. – David Dubois Feb 17 '17 at 17:40
  • Git sets the time stamp to the current time when replacing a file, specifically to address this problem. I think all version control systems do it this way. http://stackoverflow.com/a/2179876/492336 – sashoalm Feb 18 '17 at 05:08
  • I'm just describing a scenario that happened to me. – David Dubois Feb 18 '17 at 13:31
  • 1
    With your edit, the question is: Given that there's no reason for a normal build and full build to give different results, is it a bug for a normal build and a full build to give different results? – David Dubois Feb 18 '17 at 13:36

1 Answers1

1

Build systems can be optimized for performance or completeness.

Rebuild all is a completeness build.

The reason a partial rebuild fails is

  • incorrect knowledge. A library is built, but a fragmented build system does not understand the dependencies of the whole.
  • missing dependencies. Although the direct dependencies of header to c code are understood, indirect dependencies are missed.
  • edit and continue mis-compile. The partial build mid understands the consequences of a code change, and does not recompile enough.

All these mistakes are offset by the advantages

  • simpler to maintain make files
  • faster compiles
  • quicker bug turn around

You need to make your own judgement on where the value lies

mksteve
  • 12,614
  • 3
  • 28
  • 50
  • One other possibility - an artifact was partially built as part of a previous build attempt, and is now in an incomplete state. If the dependencies of this artifact are not updated, the build system would not know that the artifact needs to be rebuilt. – Stobor Mar 01 '17 at 05:32