---------------------------------------------------------------------- Dokumentation zu "M2Make" Version 1.5 Testversion "gamma" 8.Apr.1989 Autor: Nicolas Benezan, Postwiesenstr. 2, D7000 Stuttgart 60 ---------------------------------------------------------------------- Copyright ­­­­­­­­­ Das komplette Packet (siehe unten) ist Shareware, das heißt, es darf für jedermann frei kopiert werden, solange die Vollständigkeit des Programms, dieses Kopierechtvermerks und der Dokumentation gewähleistet ist. Jeder darf das Programm testen, um festzustellen, ob es ihm geeignet erscheint. Bei Benutzung über den reinen Probebetrieb hinaus wird der Benutzer gebeten, mit einem Unkostenbeitrag die Pflege des Programms und die Entwicklung neuer Software zu unterstützen (Vorschlag: ca. 25DM). Noch ein Wort zur Sharewaregebühr: Leider hat sich die Idee der Shareware hier in Deutschland noch nicht durchgesetzt, was wir (Amok) an der bisher geringen Resonanz ablesen. Ich möchte deshalb nocheinmal dazu aufrufen, dieser Vertriebsart bitte doch mehr Beachtung zu schenken. Die Vorteile der Shareware liegen klar auf der Hand: * Niemand braucht "die Katze im Sack" zu kaufen. Die Programme können getestet werden, bevor man sich entscheidet. * Es gibt keinen teueren Vertriebsweg, bei der eine Menge Händler mitverdienen. Shareware ist deshalb bei vergleichbarer Qualität billiger als komerzielle Produkte (vgl. "Make Utility" von A+L AG). * Man bekommt oftmals einen besseren Service als bei komerziellen Programmen, da man sich direkt mit dem Programmierer in Verbindung setzten kann. Probleme und Bugs werden schneller beseitigt. Die Sharewaregebühr verlange ich nicht um reich zu werden (ich verdiene genug an PC-Programmen), sondern weil ich nicht einsehe, beim Programmieren und Verbreiten von, wie ich meine nützlichen, Programmen auch noch draufzuzahlen. Ich will damit auch nicht einem armen Schüler die letzte Mark aus der Tasche ziehen, sondern ich weiß genau, das es eine Menge Leute gibt, die genug Geld haben aber ihre Sharewareprogramme umsonst benutzen wollen (sei es aus Faulheit zu zahlen, oder wegen miesem Charakter). Wenn Sie sich trotzdem dazu entscheiden (hoffentlich wenigstens noch schlechten Gewissens), Ihren Beitrag nicht zu zahlen, obwohl Sie das Programm regelmäßig benutzen, bedenken Sie bitte, daß SIE dann daran Schuld sein könnten, daß mir die Sache zu dumm wird, und ich in Zukunkt meine Programme so schreibe, daß sie nur bei mir laufen und nur ich sie bedienen kann, weil sie beim kleinsten Fehler abstürzen (ein solches Programm braucht nämlich höchstens ½ des Aufwandes eines benutzerfreundlichen). Das wäre schade, denn habe bis jetzt meine Programme immer versucht, benutzer- freundlich zu schreiben und sie zu pflegen/debuggen. "M2Make" ist keine Public Domain Software. © 1989 Nicolas Benezan Alle Rechte vorbehalten Einleitung ­­­­­­­­­­ Für all diejenigen, die noch nicht wissen, was ein "Make-Utility" ist: In Modula kann es sehr nervend sein, wenn bei einem mittleren bis größeren Projekt (mehr als 3 Module) ein Definitionsmodul neu compiliert werden muß. Es müssen dann nämlich alle Module, die dieses Modul importieren, ebenfalls neu compiliert werden. Ein "Make" nimmt einem diese Arbeit ab und untersucht automatisch, welche Module geändert wurden, und welche von diesen abhängen. In einem Durchlauf werden die erforderlichen Module dann in der richtigen Reihenfolge compiliert und das Programm anschließend gleich gelinkt. Umfang des Packets ­­­­­­­­­­­­­­­­­­ Zum vollständigen Umfang des Packets "M2Make" gehören: (Stand 17.02.89) * Make.dok (dieser Text) * Make.mod, Make.obj * ModuleInfos.def, ModuleInfos.sym ModuleInfos.mod, ModuleInfos.obj * Interface.def, Interface.sym Interface.mod, Interface.obj * SrcScanner.def, SrcScanner.sym SrcScanner.mod, SrcScanner.obj * SymScanner.def, SymScanner.sym SymScanner.mod, SymScanner.obj * ObjScanner.def, ObjScanner.sym ObjScanner.mod, ObjScanner.obj * PathFinder.def, PathFinder.sym PathFinder.mod, PathFinder.obj * Environment.def, Environment.sym Environment.mod, Environment.obj * m2m (gelinktes Make, renamed) * m2m.info (spezielles Icon) Zum Linken von Make werden noch folgende Module benötigt (bitte schauen sie im Inhaltsverzeichnis (Datei ":Inhalt") dieser Diskette nach): * MemSystem V1.2 oder höher * ErrorReq.def V1.2 oder höher * TaskMemory.def * AVL.def V1.2 oder höher * List.def V1.1 oder höher * Queue.def V1.1 oder höher "AVL", "List" und "Queue" sind von Michael Frieß, dem ich an dieser Stelle danken möchte. Bedienung ­­­­­­­­­ a) Workbench ------------ Anklicken des Hauptmoduls (zB. Make.mod) und erweitertes Doppelklicken von m2m. b) CLI ------ M2m mit den Hauptmodul (und eventuell Optionen als Argument aufrufen. Beispiel: > m2m -di :M2make/Make.mod Tip: Die Erweiterung ".mod" kann weggelassen werden; steht das Haupt- modul im txt-Dir, kann man m2m auch vom darüberliegenden Dir aus aufrufen. Beispiel: > m2m Make anstatt: > m2m txt/Make.mod Zu beachten ----------- Bitte installieren Sie m2make so, daß folgende Voraussetzungen gegeben sind. Falls das Programm nicht erwartungsgemäß funktioniert, prüfen sie erst, ob es nicht an einem dieser Punkte liegt. Es wird erwartet, daß... * Implementations- und Hauptmodule die Erweiterung ".mod" haben, * Definitionsmodule die Erweiterung ".def" tragen, * Zusammengehörende Source und Sym/Obj-Code im selben Projektordner stehen, * der Compiler "m2c", * der Linker "m2l" heißt und * daß beide in dem Directory stehen, das im m2m.info "ToolTypes"-Feld nach "SYSTEMPATH=" eingetragen ist (default: "m2:"), * daß die Systemzeit streng monoton steigend ist (siehe Vorgehensweise) * daß alle zum Programm gehörigen Module einen unterschiedlichen Namen haben, dh. wenn "A" "C" importiert, und "B" importiert "C", dann muß "C" beides mal das selbe Modul meinen. (Innerhalb der Suchpfade (globale/lokale Pfaddatei) darf es hingegen ruhig mehrere Module mit gleichem Namen geben, solange sie nicht parallel importiert werden.) Vorsicht: Es sollte Version 3.2 (oder höher) des Compilers verwendet werden. Verwenden sie ältere Versionen, beachten Sie bitte, daß die Pfaddatei ("path", nicht "m2path" im Systemverzeichnis "m2:" gesucht wird. Achten sie darauf, daß ein "ASSIGN M2:" auf ihr Verzeichnis gemacht wurde, in dem bei Ihnen Compiler und Linker stehen (bzw. Tragen sie ihr Verzeichnis in das Tooltypes-Feld ein). Installation / Optionen ----------------------- Das Fenster (bzw. die Datei), das beim Start von der Workbench geöffnet wird, kann im "ToolTypes"-Feld des Icons (m2m.info) nach "OUTPUT=" eingetragen werden. Das Verzeichnis, in dem sich Compiler und Linker sowie die Pfaddatei "path" befindet, kann nach "SYSTEMPATH=" eingetragen werden. Optionen können entweder in der Kommandozeile des CLI oder nach "OPTIONS=" bei Tooltypes angegeben werden. Beachten Sie die jeweilige Schreibweise: Beispiel: CLI> m2m -iq main.mod Tooltypes: OPTIONS=I|Q Erlaubte Optionen sind a, i, d, q, x (Bedeutung siehe unten). beim CLI ist die Groß/Kleinschreibung egal, beim ToolTypes-Feld muß man die Optionen groß schreiben und durch senkrechte Striche ("|") trennen. Leerzeichen sind nicht erlaubt. Optionen beeinflussen den Make-, Compiler- und/oder den Linkerlauf: Make-Optionen: a - es werden grundsätzlich alle Module compiliert (wenn möglich), egal ob sie geändert wurden oder nicht. Compileroptionen: i - keine Icons d - keine Referenzdateien (".ref") für den Debugger q - Modulnamen werden nicht aufgelistet Linkeroptionen: i - keine Icons q - keine Referenzdateien x - keine ausführliche Modulliste im gelinkten Programm Vorgehensweise von Make ----------------------- Bei jedem Makerlauf wird der "Importbaum" ausgehend vom Hauptmodul rekursiv untersucht, indem alle Sym/Obj-Dateien, falls vorhanden und gültig (Versionskontrolle), oder der Sourcecode gelesen wird. Dabei wird nach folgendem Schema vorgegangen: 1) Bevor ein Definitionsmodul untersucht wird, werden alle importierten Definitionsmodule geprüft. 2) Bevor ein Implementations- oder Hauptmodul untersucht wird, werden alle importierten Definitionsmodule geprüft. 3) Außerdem muß ein Definitionsmodul immer vor seiner Implementation untersucht werden. (Anm.: 3) ist übrigens gar nicht so einfach zu erfüllen, wie es aussieht. 1) gilt nämlich rekursiv auch auf die importierten Module. Deshalb ist eine Queue (Make.ModQueue) nötig, die sicherstellt, daß bevor ein Implementationsmodul untersucht wird, das Programm aus der Rekursion 1) wieder vollständig zurückgekehrt ist. Wer einen besseren Algorithmus hat, möge ihn mir bitte verraten. Aber bitte vorher gründlich nachdenken!) Neucompilieren ist notwendig, wenn: * ein importiertes Definitionsmodul compiliert wurde, * bei einem Definitionsmodul die ".sym"-Datei älter ist als die ".def"-Datei bzw. keine ".sym"-Datei vorhanden ist, oder * bei einem Implementationsmodul... wenn das zugehörige Definitionsmodul compiliert wurde, oder wenn die ".obj"-Datei älter als die ".mod"-Datei ist, oder wenn die ".obj"-Datei fehlt. Ein Wort zur Systemzeit: Um festzustellen, welche Datei älter ist (wessen Erzeugen oder Änderung länger her ist), wird das von Dos an jede Datei vergebene Datum abgefragt. Dabei muß die Systemzeit NICHT unbedingt richtig gesetzt sein. Make läuft (theoretisch) also auch auf Rechnern ohne Echtzeituhr (bzw. solchen, deren Besitzer zu faul sind, beim Booten die Zeit einzugeben). Es wird lediglich vorausgesetzt, daß die Systemzeit streng monoton steigend ist, was Dos automatisch gewährleistet. (Dos vermerkt nämlich auf jeder Diskette die Zeit des letzten Schreibvorgangs und macht vor jeder Änderung: IF SysTimeNotSet AND (DiskTime>SysTime) THEN Systime:=DiskTime END). Probleme gibts nur dann, wenn jemand sträflicherweise die Zeit rückwärts setzt, oder eine Diskette von einem Rechner, dessen Uhr auf Zukunft gestellt war, auf einem mit korrekt gestellter Uhr verwendet wird. Um unnötige Diskettenzugriffe und Zeit zu sparen, werden folgende Methoden verwendet: * Sind Sym/Obj-Dateien vorhanden und gültig (Versionskontrolle), werden sie den Def/Mod-Datei vorgezogen, da erstere schneller ausgewertet werden können. * Ein Source-, Symbol- oder Object-File wird nie zweimal gelesen, sondern Name und Zustand werden, nachdem die Files einmal untersucht wurden, im Speicher abgelegt. * Ein Pfad wird nie zweimal gesucht. Wurde ein Projektpfad einmal gefunden merkt sich das Programm den Lock. * Die globale Pfaddatei wird gleich zu Anfang im voraus gelesen. * Standard-Bibliotheksmodule (stdlib), deren Source nicht gefunden wird, werden nicht weiter untersucht, was auch sinnlos wäre, da sie sowieso nicht neu übersetzt werden könnten. * Importlisten werden auf einen Schub in eine Queue übertragen und die Source/Objektdatei gleich wieder geschlossen. Sonst wären beim rekursiven Untersuchen der Module (siehe oben) möglicherweise hunderte von Files gleichzeitig offen. Dos würde es zwar verkraften, aber besonders gesund wäre es auch nicht. Den Sourcecode vom gesammten M2Make zu erläutern, wäre an dieser Stelle übertrieben. Falls jemand Fragen dazu hat, bin ich gerne zu Auskünften bereit. Sonstiges ­­­­­­­­­ Wenn Sie eine andere Stackgröße für den Compiler/Linker wünschen - im Modul "Interface" stehen die verwendeten Werte (Konstanten). Wenn Sie bemerken, daß diese Version des Makes manchmal mit seltsamen Fehlermeldungen aussteigt (bei ordnungsgemäßer Installation eigentlich selten), daß es FileLocks frißt usw. , dann stempeln Sie es bitte nicht gleich als unbrauchbar ab. Dies ist die Gamma Testversion. Registrierte Benutzer erhalten automatisch die offizielle Version, die diese Mängel nicht mehr aufweist. Dies ist keine absichtliche Erpressung, sondern ist durch Terminschwierigkeiten bedingt. Wenn Sie je Probleme mit "Make" haben, wenden Sie sich an mich (Bitte Sharewaregebühr nicht vergessen). Bug Reports und Verbesserungsvorschläge nehme ich auch gerne von nicht eingetragenen Benutzern entgegen. ----------- Bene.