Handling of circular dependencies
We had a couple of cases where we came to the conclusion that these would impeed a circular dependency between dune modules.
Example
One example would be higher order geometries in dunegeometry
. The canonical way to implement these should be based on dunelocalfunctions
. A geometry describes a particular type of function in local coordinates. The issue is that dunelocalfunctions
already depends on dunegeometry
. This would (potentially) lead to the following setup:
Module: dunelocalfunctions
Depends: dunegeometry
and
Module: dunegeometry
Depends: dunecommon
Suggests: dunelocalfunctions
Current state
The current state is, that his might even work, although not officially supported.
dunecontrol
simply starts building a graph of all dependencies and suggesttions and when ever a module is already in the list, it will not add it again. The only difference between Suggests
and Depends
is that missing dependencies are fatal, while missing suggestions are OK.
So depending on the order in which dunecontrol
finds the modules, it might create one of two possible DAGS of the core modules (as an example). Here follow the original graph and the two possible DAGS and their respective buildorder:
graph RL
subgraph AA[Original Graph]
A:common(dunecommon)
A:geometry(dunegeometry)
A:istl(duneistl)
A:localfunctions(dunelocalfunctions)
A:grid(dunegrid)
A:geometry > A:common
A:istl > A:common
A:geometry .> A:localfunctions
A:localfunctions > A:geometry
A:localfunctions > A:common
A:grid > A:geometry
end
graph RL
subgraph D1[DAG variant 1]
B:common(dunecommon)
B:geometry(dunegeometry)
B:istl(duneistl)
B:localfunctions(dunelocalfunctions)
B:grid(dunegrid)
B:geometry > B:common
B:istl > B:common
B:localfunctions > B:geometry
B:localfunctions > B:common
B:grid > B:geometry
end
graph RL
subgraph D2[DAG variant 2]
C:common(dunecommon)
C:geometry(dunegeometry)
C:istl(duneistl)
C:localfunctions(dunelocalfunctions)
C:grid(dunegrid)
C:geometry > C:common
C:localfunctions > C:common
C:istl > C:common
C:grid > C:geometry
C:geometry .> C:localfunctions
end
graph LR
subgraph B1[Build order 1]
D:common(dunecommon)
D:geometry(dunegeometry)
D:istl(duneistl)
D:localfunctions(dunelocalfunctions)
D:grid(dunegrid)
D:common > D:istl
D:istl > D:geometry
D:grid > D:localfunctions
D:geometry > D:grid
end
graph LR
subgraph B2[Build order 2]
E:common(dunecommon)
E:geometry(dunegeometry)
E:istl(duneistl)
E:localfunctions(dunelocalfunctions)
E:grid(dunegrid)
E:common > E:istl
E:istl > E:localfunctions
E:localfunctions .> E:geometry
E:geometry > E:grid
end
As the circular dependency is only weak in the sense, that dunelocalfunctions
only requires the geometry headers but no lib, it is possible to compile this setup without problems.
Note that there might still be some issues with cmake
though...
Proposal
In order to fix this problem and be sufficiently flexible to handle such weak suggestions and weak dependencies I suggest to introduce two additional key words Requires
and Recommends
.
The semantics are then as follows:

Depends
: requirements that need to be built first (e.g. we might require libs built in these modules). 
Suggests
: same asdepends
, but we are still functional without these modules. 
Requires
: we only require the headers, but these relations don't impact the construction of a DAG (in particular we don't require any libs or other compiled artifacts from these modules). 
Recommends
: same asRequires
, but we are still functional without these modules.
Alternative names might also be WeakDepends
and WeakSuggests
... in general I'm open for suggestions.