Shade Of Mine schrieb:
hustbaer schrieb:
Und dann sehe ich keine Notwendigkeit die Dependencies überhaupt irgendwann neu zu generieren.
Du brauchst immer ein Clean. Immer. Egal was.
Und da wird es doof wenn der Compiler dein Make-Clone ist. Denn du brauchst ein make clean, ein make all, ein make target, etc.
OK, so meinst du das. Ja, geht ja alles. Make clean = alle Intermediate-Files löschen. So lange man die Metadaten (d.h. Dependencies oder was sonst noch anfällt) in Files speichert geht das ja. Und wenn man die Intermediate-Files in einem eigenen Verzeichnis sammelt, ist das hübsch einfach und unabhängig davon welche Filenamen/Extensions irgendwelche Tools produzieren/verwenden. Einfach das ganze Verzeichnis löschen und gut.
Shade Of Mine schrieb:
Wenn wir jetzt davon ausgehen dass wir nie auf diese Metadaten zugreifen muessen und das System mit den Compilern perfekt funktioniert: welchen Vorteil haettest du?
Du brauchst immer noch ein Buildsystem. Abhaengigkeiten gibt es viel mehr als nur die Includes. Mehrere Buildschritte, unterschiedliche Targets, etc. Du wuerdest dir hier deutlich mehr Komplexitaet einkaufen, weil Compiler ploetzlich "mitdenken" und das beachtet werden muss.
Mir geht es dabei darum dass ein generisches Tool wie make (bzw. ein anderes Build-System) nichts über die Eigenheiten der Sprache wissen sollte.
Beim Programmieren irgendwelcher Anwendungen würde man das ja auch nicht so machen. Also zwei strikt getrennte Module zu machen (unterschiedliche Hersteller, getrennt versioniert etc.), von denen eines über die "Innereien" des anderen Bescheid wissen muss, damit es "voraussagen" kann was das andere Modul brauchen wird um irgend eine Aufgabe zu erledigen.
Damit dass man den Compiler verwendet um die Liste der Dependencies zu erzeugen vermeidet man natürlich einen Teil der Probleme. Allerdings hat man dann immer noch eine Schnittstelle zwischen den beiden Tools die eigentlich unnötig ist. Und Probleme verursachen kann, z.B. dadurch dass sie bestimmte Dinge nicht kann/versteht. z.B. ist die Schnittstelle wie sie momentan verwendet wird - wenn ich es richtig verstanden habe - dahingehend limitiert, dass make nicht feststellen kann wenn sich include-Verzeichnisse geändert haben. Das muss der User dann wissen und manuell clean aufrufen.
Und das könnte man mMn. eben vermeiden.
Andere Frage dazu: Kann make korrekt mit gleichnamigen .c und .h Files in verschiedenen Verzeichnissen umgehen?
Shade Of Mine schrieb:
Das tolle an dem Unix-Ansatz ist ja, dass jede Anwendung nur fuer einen kleinen Teil zustaendig ist und das man sich komplexe Loesungen baut indem man viele kleine Anwendungen aneinander stoppelt.
Mir der "Unix-Ansatz" schon klar. Mir ist aber auch klar zu welchen Problemen er führt wenn man versucht überall damit zu arbeiten. Und speziell wenn man es macht ohne zu berücksichtigen was es für Folgen hat. Dabei fällt mir z.B. die tolle Idee ein den Output von tar direkt nach gzip rein-zu-pipen. Was dann dazu führt dass Fehler die tar meldet einfach gefressen werden. (Oder gibt es auch dazu eine Lösung die ich bloss nicht kenne?)
Aber zurück zu Build-Systemen. Sagen wir ich schreibe einen C# Compiler. Oder auch einen Compiler für eine ganz neue Sprache X. Und sagen wir dieser C# bzw. X Compiler braucht zwei Durchgänge die man getrennt aufrufen muss. Einen um die Metadaten der in den Source-Files definierten Klassen zu extrahieren, und einen zweiten der diese Metadaten dann verwendet (damit er weiss was für andere Klassen existieren und wie diese aussehen) um das eigentliche Kompilat zu erstellen.
Würdest du dafür dann das Build-System erweitern wollen, damit man diesen C# bzw. X Compiler verwenden kann? Was wenn Version 2 dieses Compilers beschliesst statt einem Metadaten-File pro Source-File nur ein einziges Metadaten-File zu verwenden in dem er alle Metadaten sammelt? Müssen wir dann alle Build-Tools anpassen?
Ich würde es nicht wollen. Ich würde sagen: Was der komische X Compiler da mit den zwei Durchgängen macht, das soll er gefälligst so machen dass das Build-System davon nichts wissen muss. D.h. der X Compiler soll ein Frontend bereitstellen das man mit allen Source Files auf einmal aufrufen kann, und sich um seine Durchgänge, Intermediate-Files und interne Abhängigkeiten selbst kümmern.
Und das selbe würde ich eben auch für C oder C++ Compiler sagen.
