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.

Diese Konflikte müssen erkannt werden und zu einem Fehler führen. Dadurch ist ein konsistent wiederholbarer Bauprozess möglich, gleich welches Grad an paralelität eristiert.

Damit erkannt wird, welche Dateien gelesen und geschrieben werden, müssen die Zugriffe der gestarteten Bauprozesse Überwacht werden. Dabei sollten destruktive Zugriffe unterbrechbar sein (um um Zustimmeng des Nutzers zu fragen). Die gelesenen und geschriebenen Dateien werden Protokolliert (dependencies von *.c). Zudem werden die Bentzen resourcen protokolliert um beim nächsten durchgang den grad an möglicher Paralelität genauer zu bestimmen.

Sind Ein- und Ausgabedateien von Tasks das richtige Mas um die Baureihenfolge zu bestimmen?

• Vor der Ausführng sind nicht alle Ein- und Ausgabedateien eines Tasks bekannt.
• Pieline aus Modifikationen einer Datei: Wie sollen die Schritte angeordnet werden?

⇒ ggf. ausschließliches/zusätliches matching von Ausführbaren Tasks:

• in := (($1.tpl)[tplGenerator])
• in := ([createEmail])

Tasks werden mit einer leeren umgebung ausgeführt. Umgebungsvariablen müssen explizit durchgereicht werden.

Der Task wird standartmäsig zum 1.1.1970 ausfeührt. Andere Daten müssen explizit durchgereicht werden.

Was wird mit Netzwerkverbindungen gemacht? Verbieten, Whitelists, Fragen, hashen (problem TLS), proxy (nur HTTP).

Was soll mit Symlinks passieren? Was, wenn sich ein Symlink von einer zur nächsten Ausführung ändert?