Probleme mit einem Make (ja, das meiste kann man mit hacks oder configurationen umgehen, aber dann ist der Bau prozess nicht mehr so simpel wie möglich):

• Man müllt sich sein source Verzeichniss mit Temporären Dateie voll (insb. LaTeX, gcc mit *.s, *.lst, *.i files)
• Mehrere Ausgabedateien sind nicht möglich (split-Prozesse)
• Noch unbekannte Ausgabedateien sind nicht möglich (Eurzeuge mehrere Dateien aus einer DB)
• Alle input Dateien können nicht immer leicht vorher bestimmt werden (includes von C)
• Dateien, die in-, wie output sind, sind nicht möglich
  • Ein und die selbe Dateien so lange bearbeiten, bis sie konvergiert (hash file bei latexmk)
  • Ein und die selbe Datei durch verschiedene Prozesse lafen lassen (filter pipelines)
• Sichere asführung
  • Veränderungen auserhalb des Projektverzeichnisses mit Rückfrage (sudo make install)
  • Keine destruktiven veränderungen des source verzeichnisses (make clean löscht aus versehen auch die sourcen)
  • Warum nicht gleich auch (als extra feature, nicht als standard Fall) das bauen in containern ermöglichen (Task weise), so dass man z.B. Pakete für diverse distros bauen kann.
• Dynamisch Paralellisierung (linken braucht mehr ram compilieren, wechselnde last auf Desktoprechnern, unterschiedliche bauumgebungen)

Es wird in einer “Schattenwelt” gearbeitet. Ein overlay verhindert, dass der Source Ordner verändert wird. Die Ergebniss-Dateien müssen expliziet durchgestochen werden, so dass die im eigentlichen Projektordner wieder landen.

Veränderungen in diesem overlay werden werden durch parallel laufende Tasks vorgenommen. Deren Ergebnisse müssen in den master-Overlay gemerged werden. Dies wird wie DB-Trannsaktionen behandelt. Es können also die selben konflikte auftreten:

• Zwei Tasks, die zusammen ausgeführt werden konnten, haben die selbe Datei geschrieben.
• Ein Task hat von einer Datei gelesen, die ein anderer geschrieben hat, welche zur selben Zeit hätten ausgeführt werden können.