Bis jetzt ist noch nichts Spektakuläres an diesem Konzept zu erkennen. Es liegt auf der Hand, alle zusammengehörenden Moduln in einem eigenen Verzeichnis abzulegen. Wir haben aber vorher gesehen, dass es viele verschiedene Typen von Dateien gibt. Sie unterscheiden sich durch spezifische Endungen:
Schaut man sich ein Projektverzeichnis mit dem Befehl dir des Betriebssystems an, stehen aber nicht alle Dateien gleichen Typs beieinander, sondern man findet alle Dateien, die zu einem Modul gehören, alphabetisch aufgelistet. In unserem Beispiel des Compilers sieht das Projektverzeichnis folgendendermassen aus:
1> dir Compiler Compiler.mod Compiler.obj Compiler.ref Generator.def Generator.mod Generator.obj Generator.ref Generator.sym Parser.def Parser.mod Parser.obj Parser.ref Parser.sym Scanner.def Scanner.mod Scanner.obj Scanner.ref Scanner.sym
Die Liste ist zwar alphabetisch, aber bereits diese vier Moduln ergeben eine recht lange Liste; dabei sind gar keine Versionen für höhere Prozessoren vorhanden. Oftmals wäre es besser, wenn man alle Dateien des gleichen Typs beieinander hätte. Um dies zu erreichen, kann man das Projektverzeichnis mit Unterverzeichnissen weiter unterteilen. Unser Projektkonzept erkennt Unterverzeichnisse mit folgenden Namen:
Wichtig ist, dass es nicht zwingend ist, mit diesen Unterverzeichnissen zu arbeiten. Man kann sie einrichten, wenn man sie möchte; man kann aber auch alle oder einen Teil davon weglassen. Wenn man aber ein Unterverzeichnis eingerichtet hat, muss man es benutzen. Das heisst, dass bei einem vorhandenen Unterverzeichnis ,,txt`` alle Programmquellen in diesem abgelegt werden müssen. Existiert also ein Unterverzeichnis ,,txt``, werden alle Texte, die direkt im Projektverzeichnis abgelegt sind, von allen -Programmen ignoriert.
Das Beispielprojekt könnte also aussehen wie in Abbildung 2.1.
Hierbei wurde das ,,bin``-Unterverzeichnis weggelassen, so dass sich das vollständig gelinkte Programm ,,Compiler`` direkt im Projektverzeichnis befindet.