Ideas for a new Make alternative

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?

Siehe auch Gentoo's sandbox und Debian's fakeroot.

Beim Mergen Der Task-Overlays in den Master-Overlay nicht exakt wie weine DB-Vorgehen (nur tatsächlich paralell ausgeführte Tasks (transaktionnen) auf Konflikte testen), sondern alle aktionen von Tasks beachten, die hätten parallel ausgeführt werden können.

Das master-overlay darf nicht direkt auf den sourcen liegen, sondern auf einem Snapshot derer, so kann man während dem bauen an den sourcen weiter arbeiten.

Die Tasks dürfen auch nicht direkt auf dem master-overlay arbeiten. Nur Tasks, die aus dem selben Task-Set (Tasks die parallel ausgeführt werden dürfen) sind, können auf dem selben snapshot arbeiten. D.h. ein neuer master-snapshot muss nur erzeugt werden, wenn ein neues Taskset berechnet wird. Denn wenn die Tasks sagen, sie können gleichzeitig laufen, sind sie auch nicht auf die neusten files ihrer “mitläufer” angewiesen.

Problem:
Tasks, bei denen die Ausgabedateien nicht vorher bekannt sind, erstellen die selbe Datei.

Lösung:
Fehler + Programmabbruch. Der Benutzer muss das Fixen.

Problem:
Tasks liest die selbe Datei, die es auch Schreibt.

Lösung:
Maximale anzahl der Ausführungen der Task-Instanz festlegen.

Problem
selbes file wird von verschiedenen Tasks bearbeitet (Filter/Produuktionskette).

Lösung:

• Task + File als dependency angeben
• oder: Das verhalten verbieten und ein Task ruft mehrere Programme sequentiell auf.