So ganz kann ich das nicht verstehen. Tools, die "Projekte" verwenden haben jedes ihr eigenes System. KiCad erzeugt dazu einen Ordner und legt eine Datei gleichen Namens (was ich mir nicht aussuchen kann) mit der Endung .pro (die ich nicht frei wählen kann) in diesem Ordner an. So What
MplabX legt einen Ordner mit dem Projektnamen und der Endung .X an. Ist nun mal so. Beide tun das, um zu erkennen, daß es sich um ein für sie relevantes Projekt handelt. Andere Systeme machen es anders, erwarten z.B. immer eine package.json im Projektdirektory oder irgendeine Lizenzdatei, auch wenn ich sie nicht brauche. Wenn man das nicht will, darf man das entsprechende Tool nicht benutzen.
Jetzt zu
Wenn ich MplabX als "Filemanager" benutzen wollte, würde ich auch nicht "Projects" sondern "Files" benutzen.Wenn ich z.B. einen Verzeichnisbaum im Projektfenster der IDE sehe, der nicht annähernd mit meiner Verzeichnisstruktur übereinstimmt bin ich schon überfordert.
Ich hab die Darstellung im Projektfenster nie als "Verzeichnisbaum" betrachtet. Für mich ist das die logische Struktur meines Projektes, nicht die physikalische. Es ist so etwas wie die graphische Darstellung des Makefiles. Alles was in "Source" dargestellt ist, muß übersetzt werden, die Headerfiles natürlich nicht. Ändert sich ein Sourcefile, muß nur dieser übersetzt und alles gelinkt werden. Hat sich eine Library oder der Linkerfile geändert, muß nur neu gelinkt werden. Hat sich ein Headerfile geändert, müssen alle Sourcen, die diesen anziehen neu übersetzt werden. Wo die Files liegen ist da nicht vorgegeben. Manche Sourcen und Header gehören auch zu anderen Projekten und liegen ganz woanders. So benutze ich eine gemeinsame Sourcelibrary für I2C, die zentral an anderer Stelle liegt. Wenn die irgendwann stabil ist, entferne ich sie aus dem Sourcezweig und setze nur noch das Objekt in den Libraryzweig. Ich finde das alles ganz übersichtlich.
Bei selbstgebauten Buildumgebungen macht man das ähnlich, benutzt aber gerne das Filesystem für die Zuordnung der Files und baut sein Makefile passend auf. So übersetzt man z.B. alles was in "./source" steht. Will man da etwas externes mit drin haben, setz man einen Link auf diesen File nach source. Erzeugt man einen weiteren Sourcefile am falschen Platz, wird er nicht berücksichtigt. Liegt ein Objekt am falschen Ort, wird es nicht gelinkt. Dafür darf man Versuche die beim deguggen so entstehen, nicht in ./source lassen, da sie sonst immer mitübersetzt werden und mir spätestens beim linken Probleme machen. Das kann man so mögen oder auch nicht.
MfG Klebwax
Lesezeichen