Dependencies in FDL

In most of the flow examples, we have not shown any explicit dependency, mostly because we have used J rather than T.

In practice, it is common to use the FDL procedures I and O to describe basic dependencies in the jobs. Both I and O must follow the job to which they refer. For example:

T vw cp $in $out
I $in
O $out

Important:

The dependencies you describe in the Flow Description only form the starting point of the flow graph.
In FlowTracer the dependencies for each job are dynamically computed by the tool integration at run time.
In FlowTracer all jobs must have at least one output dependency in order to be considered valid.
In Accelerator, there is no runtime tracing, and the flow graph is not updated at run time.

Incorrect Dependencies

Incorrect dependencies may create problems. Given that runtime tracing will fill in the dependency details, you should only specify a minimum set of dependencies in your flow description and let runtime tracing fill in the rest automatically.

Incorrect Input Dependency
```
# Incorrect input dependency
T vw cp aa bb
I cc;     ##### incorrect input
I aa 
O bb 
```
This example will generate an spurious input in the flow. If the file cc changes, it will invalidate the job and will cause it to be re-run needlessly. However, running the job will fix the input dependencies for bb by dropping the dependency on cc.
Incorrect Output Dependency
```
# Incorrect output dependency
T vw cp aa bb
I aa 
O bb 
O cc; ##### Spurious output
```
This example will generate a spurious output in the flow. However, running the job will fix the output dependencies by dropping the output dependency on cc.

Arbitrary Dependencies with DEPENDENCY or with AD

The procedures DEPENDENCY (and its synonym AD) take two list of IDs as parameters. In the common form, they take two simple IDs:

DEPENDENCY $J1 $J2

or

AD $J1 $J2

These procedures create a PHANTOM place and declare it as a sticky output to the job with VovId J1 and as a sticky input to the job with VovId J2.

Example:

set j1 [J vw cp aa bb]
set j2 [J vw cp aa cc]

# Force the second job to be executed after the first job, even
# if there is no particular reason for it. You can also use the
# short name 'AD' (for Artificial Dependency).
DEPENDENCY $j1 $j2

The flow above can be written more concisely as:

SERIAL {
    TASK cp aa bb
    TASK cp aa cc
}

which also creates an artificial dependency between the two tasks by means of a "sticky phantom". This is one way to force a job to have an output without explicitly declaring it at runtime.