Thinking about the queue

The heart of our build system is going to be a queue of tasks. This is easy to visualise, tasks get popped onto the queue by one thread and another loops over them, interogating each one to see if it should be run. However that last part brings with it a multitude of complications.

For many tasks things are relatively simple. They take a file and produce another file. In this case the test need only be "does the intput file exist?"

Things get more complicated from there.

Even apparently simple tasks like compiling a Fortran source file are more complex than they first seem. Although a Fortran compiler takes a Fortran source file and produces an object file it is not that simple. If any modules are used it also depends on those .mod files existing. (Except where the compiler doesn't produce .mod files but has some other mechanism for storing module information, such as the Cray compiler storing it in th eobject file itself)

Linking is another example of a task which requires a number (possibly a large one) of input files.

How to track dependencies

There are a number of potential solutions to tracking whether a task is fit to run, i.e. all its dependencies are fulfilled. In this page we present them and discuss their pros and cons.

The task knows

Scoreboard

Not a queue