Eclipse Workspace und Projekte

Eclipse Workspace und Projekte

Inhalt


Topic:.EclipseWrk.

Last changed: 2020-01-01

Häufig wird ein Eclipse-Projekt, für Java oder für Embedded C/++, so aufgezogen, dass ein Workspace angelegt wird. Im Workspace befinden sich ein oder mehrere zusammengehörige Projekte. In den Projekten befinden sich die Quellfiles, projektspezifisch oder kopiert aus ähnlich gelagerten Vor-Projekten. Libraries werden per Pfad eingezogen.

Das erscheint einfach, so gewollt von der Eclipse-IDE und dem Arbeitsstil entsprechend. Das "Advanced"-Button bei Anlage oder Einbeziehen von Files wird nicht genutzt.

Alles miteinander gebunden. Hat das Nachteile? Siehe Abschnitt Chapter: 1 Nachteil eines Gesamt Workspace/Projekt/Quellen-Arbeitsbereich - Was gehört zu einem Produkt und ist wie zu archivieren

Diese Kurzdoku beschreibt, wie ein Eclipse-Projekt aufgeteilt wird in

Alle diese drei befinden sich an verschiedenen Speicherorten auf der Festplatte, sind referenziert. Das Warum und Wie wird im Artikel beschrieben. Zusätzlich oder damit zusammenhängend wird auf den Aufbau eines Produktes aus Komponenten eingegangen.


1 Nachteil eines Gesamt Workspace/Projekt/Quellen-Arbeitsbereich - Was gehört zu einem Produkt und ist wie zu archivieren

Topic:.EclipseWrk.disadv.

Der Vorteil ist schon einleitend dargestellt: Alles ist beieinander. Außerdem scheint das der gewollte Stil bei der Arbeit mit Eclipse zu sein (?). Vergessen werden dabei allerdings eingezogene Libraries, siehe Chapter: 7 Die Crux mit den vergessenen Libraries, Denken in Komponenten.

Sind Workspace, Projekte und Sources in einem Arbeitsbereich, dann umfasst dieser sehr viele Files:

Wenn man davon ausgeht, dass diese Detailhaftigkeit nicht interessiert: Es wird halt alles archiviert, dann wäre das ok. Speicherkapazitäten sind groß genug - und wer interessiert sich wirklich schon für alle Details in archivierten Softwareständen. Es wird wenn nötig wieder restauriert, möglicherweise sollte man die gleiche Eclipse-Version verwenden, die sich auch bei wesentlicher PC-Plattformänderung über Jahre in VMs (VmWare häufig verwendet) packen lässt. Also was soll's? - Dies ist eine Herangehensweise.

Dieser alles umfassende Workspace umfasst nicht:

Es kann sein dass eine Neugenerierung mit einem neuen Versionsstand der Toolsoftware andere, bessere Ergebnisse liefert. Häufig sind diese genau so gut lauffähig, vielleicht optimiert. Es kann aber auch sein, dass ein Softwarefehler mit einem gegebenen Tool- und Librarystand A nicht auffällt, also unbemerkt bleibt, in einer anderen Version aber dann doch zutage tritt und als unbekannter Altfehler Ärger bereitet.

Man geht also fehl in der Annahme, das Archivieren des gesamten Workspace wäre sicher und ausreichend, man hat dabei die Libraries vergessen (!).

----------------------------------------------------------

Die andere Herangehensweise geht davon aus, dass genau bekannt sein sollte, wo was steht und wie etwas funktioniert ("Was die Software im Innersten zusammenhält").

Die wirklich wichtigen zu archivierenden Quellen der Software für eine Nachbearbeitung, Fehlersuche und Wiederverwendung sind

=> langfristig zu archivieren:

Dagegen

=> kann jederzeit auch täglich wieder generiert werden:

Diese können am Tagesanfang, zu Beginn der Session neu generiert werden. In normalen Projekten dauert eine solche Generierung wenige Sekunden.

Die Settings

=>sind arbeitsplatzspezifisch

Sie enthalten auch beispielsweise geänderte Erscheinungsformen (Appearance) der Schriftgrößen, Farben, aber auch Key-Settings. Wie diese letztlich eingestellt sind, hat keinen Einfluss auf das Software-Ergebnis, ist aber dem Bearbeiter wichtig. Man kann diese Einstellungen auch exportieren (File->Export) um sie in einem anderen Workspace wieder zu importieren (File->Export). Die Einstellungen sind dann in den exportierten Files häufig auch in nachvollziehbarer (lesbarer) Form außerhalb von Workspace und Projekten speicherbar. Da diese Files wie oben schon erwähnt keinen Einfluss auf das Softwareergebis haben, gehören sie also auch nicht zur Versionierung der Software, wohl aber zu Einstellungen zum Tool oder auch persönlichen Einstellungen.

=> braucht man nicht aufzuheben:

=> Ist mit der Toolversion gegeben:

In der Regel sollte man Installationsfiles des Tools aufheben, damit jedenfalls die originalen Compiler- und weitere Tools wieder hergestellt werden können. Man sollte auch an ergänzende Generiertools denken, die evtl. selbst erstellt wurden und nicht im Internet im nachhinein auffindbar sind. (!) Die Tools selbst gehören nicht in das normale Software-Versionsmanagement, wohl aber in die Archivierung zu einem Produkt.


2 Eclipse-Workspace neu anlegen und Projekte importieren

Topic:.EclipseWrk..

Der Workspace mit importiereten Projekten enthält:

Wenn man (beispielsweise auf einem anderen PC) einen neuen leeren Eclipse-Workspace ausweist und mit diesem Pfad Eclipse öffnet, dann enthält die Eclipse-IDE kein Projekt, die Default-Settings und bereits wieder viele temporäre Files.


Man tut nun gut daran, die Settings als Prefernces exportiert zu haben oder dies jetzt am anderen PC noch zu tun, und diese im neuen Workspace zu importieren.

Diese Settings ersetzen also die im Workspace gespeicherten

<=> als *.pref personenbezogen gespeichert und restauriert


Wenn man ein neues Projekt anlegt, dann gibt es die Möglichkeit, die Checkbox Use default location abzuwählen und statt dessen eine gewünschten Platz für das Projekt anzugeben.

Damit ist schonmal Workspace (mit den vielen temporären und nicht projektspezfischen Settings) getrennt vom Projekt selbst.

Wie am Pfad Location am Laufwerksbuchstaben T: erkennbar, das Projekt wird auf der Ramdisk angelegt, ist also äußerst flüchtig weil der RAMdisk-Inhalt nicht gepspeichert wird. Man kann anstelle auch eine Location einer Festplatte verwenden. Die Prokektfiles können und sollten danach von der RAM-Disk auf einen enstprechenden festen Platz auf der Festplatte kopiert werden, da sie dauerhaft gespeichert werden müssen. Das ist im Detail in Chapter: 4 Das Eclipse-Projekt auf der RAM-Disk beschrieben.


Hat man ein Projekt irgendwo gespeichert, zum Beispiel wie vorgeschlagen auf der RAM-Disk, oder auch innerhalb eines anderen Workspaces, dann kann man es importieren, wie rechts gezeigt wird. Eigentlich wird damit ausgeführt add Project to Workspace, importieren ist etwas irreführend denn das Projekt wird nicht in den Workspace hineingezogen sondern mit dem Import lediglich referenziert.

Das Projekt wird im Workspace unter .metadata/.plugins/org.eclipse.core.resources/.projects referenziert, möglicherweise auch noch an anderen Stellen. Das braucht man aber nicht zu wissen und zu beachten, denn der Import lässt sich beliebig oft an anderer Stelle wiederholen.


Im neuen Workspace sollte man dann auch die irgendwo am PC projektunabhängig gespeicherten Preferenzen (Einstellungen der IDE) importieren.


3 Sinn und Zweck einer RAM-Disk

Topic:.EclipseWrk.RamDisk.

Die RAM-Disk als Speichermedium am PC benutze ich schon erfolgreich seit vielen Jahren. Erstmalig war dies an einem Industrie-PC, der 'nur' eine 4 GByte-Flash-Festplatte hatte. Es gab schlechte Erfahrungen mit häufigem Schreiben auf Flash-Disks, so dass temporäre Files im eigentlich groß bemessenen Arbeitsspeicher (damals auch ca. 2 GByte) Platz finden konnten. Die Idee der RAM-Disk war aber gut, so dass ich sie seither auch auf dem normalen Arbeits-PC/Notebook verwende. Bewährt hat sich: http://www.radeonramdisk.com/.

Es ist nicht notwendig, den Inhalt der Ramdisk als Image auf der Festplatte zu speichern da die RAM-Disk eigentlich für temporäre Files und Compilate verwendet wird, die man am Anfang einer Session sowieso neu erstellen sollte (Build-all-Mentalität hat sich bewährt). Man kann auf die RAM-Disk auch das gesamte TEMP-Directory umleiten (TEMP-Umgebungsvariable umbesetzten), denn alle temporären Dinge sind, wie der Name auch sagt, temporär, nicht aufhebenswürdig.

Die Möglichkeit mit einer RAM-Disk mit gespeichertem Image zu arbeiten ist dann gut, wenn man auch extrem schnelle Lesezugriffe braucht, etwa im Server/Datenbanken-Bereich. Dafür gibt es die kostenpflichtigen Versionen mit bis zu 64 GByte RAM-Speicher (oder mehr), das trifft aber nicht unsere Zwecke.

Die Files, die häufig hauptsächlich geschrieben sind, sind bei der Arbeit als Softwareentwicker:

Bei der Filegruppe d) habe ich mir angewöhnt, Ergebnisfiles mit den gespeicherten Musterfiles zu vergleichen, zu bewerten, und ggf. die Musterfiles, die auf der Festplatte stehen, damit upzudaten. Damit ist die Filegruppe d) auch gut auf der flüchtigen RAM-Disk aufgehoben. Ähnlich ist es mit den c) Log-Files, die ggf. für den Test als Muster verglichen werden müssen, sonst aber eher temporär sind.

Wie groß soll die RAM-Disk sein? Erfahrungsgemäß reichen auch 500 MByte. Nur wenn man große Logfiles erzeugt, wird dieser Rahmen gesprengt. Da man auf einem Entwickler-PC oder Notebook heutzutage aber durchaus 16 GByte Ram hat, kann man locker 1 GByte abknapsen für die RAM-Disk, auch 4 GByte, die braucht man aber nicht. Schreibt man die RAM-Disk mit irgendwelchen Logs voll, dann kann es schonmal eine unklare Situation geben, da die meisten Programme auf die 'Disk is full'-Situation nicht sauber programmiert sind. Es hilft: Zwischendurch mal kontrollieren, wie voll die RAM-Disk ist.

Die RAM-Disk hat den Vorteil der sehr hohen Schreibgeschwindigkeit. Das ist insbesondere gegenüber der traditionellen magnetischen Festplatte wichtig. Eine SSD ist zwar heutzutage nicht mehr so sensibel auf häufige Schreibvorgänge, aber auch hier spart die RAM-Disk für die häufig neu erzeugten nur temporären Files erheblich.


4 Das Eclipse-Projekt auf der RAM-Disk

Topic:.EclipseWrk.EclPrjRam.

Gehört nun das Eclipse-Projekt auf die RAM-Disk. Eigentlich eher nicht, denn die Projektfiles sind wichtig und sollen nicht flüchtig sein. Aber: Eclipse hat die Eigenschaft, die Compilate in den Projektbereich zu schreiben, in das bin-Verzeichnis. Ich habe bisher nicht gefunden, dies umzustellen.

Bei Visual Studio kann man die Lage des Output Directory umlegen (Project->Properties Page->General-Dialog), Visual Studion baut aber sein *.db-File in die Projektumgebung. Das ist aber eher überschaubar, dieser ebenfalls nur temporär notwendige jeweils neu erstellbare File wird bei mit mit einem _clean.bat bei Bedarf gelöscht. Genau daher lohnt es sich bei Visual Studio auch, die gleiche Verfahrensweise zu nutzen und das Projekt beim Arbeiten auf der RAM-Disk zu halten.

Die Projektumgebung auf Festplatte ist bei mir meist wie folgt organisiert:

D:/Path/to/workingDir                     ...Arbeitsbereich
D:/Path/to/workingDir/src                 ...dort projektspezifische Sources
D:/Path/to/workingDir/MyProjectAbc.eclpj  ...Projektfiles als copy von RAM-Disk
D:/Path/to/workingDir/_copy_t.bat         ...copy-batch zum Kopieren

Die copy-batch enthält:

xcopy /S/E MyProjectAbc.eclpj T:\\Eclipse_PJ\\MyProjectAbc.eclpj\\*
pause

Das xcopy legt dabei die notwendigen Pfade an. Die _copy.bat ist manuell aufzurufen, am Start der Session. Man hat über die pause dann auch die Kontrolle, das alles gelaufen ist.

Ändert man Project-Settings, also wie hier im Beispiel C/++-Anwendung Include-Paths, addiert Files oder dergleichen, dann steht dies in den Files

.ccsproject
.cproject
.project
.classpath (für Java-Projekte)

Diese können in der veränderten Form manuell wieder auf die Festplatte kopiert werden. Auch ein automatisches copy per Batch ist möglich, wobei dies dann nicht vergessen werden darf. Man kann auch erst am Ende der Session kopieren, und per Vergleich, einfach auch über das manuelle Ansehen des File-Datums, die Änderung erkennen. Es gibt gute View-Diff-Tools als File-Vergleich. Dies manuell auszuführen hat den Vorteil, dass man sieht, welche Files welche Informationen enthalten. Man lernt also, wenn man in die Files hineinschaut, on-the-fly den Aufbau der Projektstruktur des Eclipse kennen, was hilfreich sein könnte.

Bei Visual-Studio ist dies fast noch einfacher. Dort sind es die drei Files

MyProject.sln
MyProject.vcxproj
MyProject.vcxproj.filters

die alle Projektinformationen komplett enthalten. Nur diese drei sind aufzubewahren bzw. hier zu kopieren.

Vergisst man zu kontrollieren ob sich in den relevanten Files auf der RAM-Disk etwas geändert hat, und fährt den PC herunter, dann sind die Änderungen weg. Meist sind diese aber nachholbar. Fehlt ein Include-Path oder File, dann fällt dies auf. Die Erinnerung wo dieser steht ist meist noch vom Vortag da. Das Vergessen ist also weit weniger kritisch als komplexe Änderungen in Sources. Die Sources stehen direkt auf der Festplatte, siehe folgend.


5 Source-Files im Projekt als Link

Topic:.EclipseWrk.srcLnk.

Was bei anderen IDEs selbstverständlich ist, ist bei Eclipse mit dem Zusatz-Button Advanced erreichbar: Die Source-Files für das Projekt werden als Link gespeichert und können sich also irgendwo anders im Filesystem befinden.

Bei Visual Studio werden relative Pfade automatisch in den Projektfiles (*.vcxprj und *.vcxproj.filters) gespeichert, wenn kein anderer Laufwerksbuchstabe angegeben wird. Das hat aber den Nachteil, dass die Projekte nicht einfach auf eine RAM-Disk kopiert werden können, denn dort stehen nicht die Sourcefiles. Man muss daher aus dem projekt auf der RAM-Disk stehend die Files auf der Festplatte addieren und erhält damit ebenfalls absolute Pfade.


Bei Eclipse kann man einzelne Files in Subdirectories im Projekt addieren, indem das Advanced-Button betätigt wird und der absolute Pfad angegeben wird. Man kann damit einzelne Files auswählen, die compiliert werden sollen. Auf die gleiche Weise lässt sich aber auch ein Directory einbinden, dessen alle Files also zum Projekt gehören und compiliert werden. Das ist häufig gewünscht. Einzelne Files kann man dann ausblenden, indem sie über ihre Properties vom Build ausgeschlossen werden.

Achtung: Das im Beispiel-Bild gezeigte Source-Verzeichnis gehört zum Projekt und bleibt dort leer. Es muss in den Projekt.Baum auf der Festplatte mit gespeichert werden (beim copy berücksichtigen) obwohl es leer ist. Ansonsten zeigt das Projekt den verlinkten File nicht an.

In den Projektfiles .project entsteht für das Beispielbild der Eintrag:

<projectDescription>
  <linkedResources>
   <link>
     <name>Source/Test_Ctrl.c</name>
     <type>1</type>
     <location>D:/vishia/emcTest/Test_Ctrl/src/Test_Ctrl.c</location>
   </link>
 </linkedResources>

Es handelt sich also um einen absoluten Pfad (anders als bei Visual Studio) was allerdings den Vorteil hat, das genau daher das Projekt auf der RAM-Disk stehen kann wogegen die Files selbst als Sources in den entsprechenden Festplatten-Verzeichnissen stehen.

Der absolute Path hat aber nun den Nachteil, dass das Projekt auf die Location auf der Festplatte festgeschrieben ist. Es sind zwei Arbeitsweise möglich, wenn mehrere Kollegen das Projekt unabhängig bearbeiten und die Projektfiles konsistent sein sollen:

Die Variante A) soll eingehender beleuchtet werden:

Eine einheitliche Projektstruktur auf der Festplatte jedes Nutzers ist empfehlenswert. Dennoch verbleibt das Problem, parallel in verschiedenen Verzeichnissen möglicherweise verschiedene Versionen zu testen, insbesondere bei einer Fehlersuche oder einem Vergleich. Man kann dazu auch mehrere PC's benutzen und hat so den Vorteil, den Vergleich direkt auf verschiedenen Bildschirmen die IDEs zu haben; Um Files zu vergleichen gibt es eine Netzwerkkopplung. Also wäre die einheitliche Projektstruktur eine machbare zu favorisierende Herangehensweise. Was dagegen spricht: Die Praxis.

Gäbe es unter Windows den gleichen Mechanismus des Symbolic Link wie es im Unix-Filesystem immer schon möglich ist, dann könnte man Quell-Pfade mit einem einheitlichen projektspezifischen Link-Verzeichnis addressieren, was im Filesystem des jeweiligen Anwenders anzulegen wäre (mit einfachen cmds) und immer anlegbar ist. Naming-Conventions würden jedweden clash verhindern.

Leider gibt es aber zwar mittlerweile im Windows-Betriebssytem für spezielle Fälle Symbolic Links, die insbesondere vom Explorer unterstützt werden. Das sind aber Symbolic-Links des Windows und Explorers und funktionieren nicht direkt auf dem Filesystem, sind also nicht für alle Tools (Compiler) wirksam.

Die Laufwerks-Substituierung mit dem subst-Cmd gibt es immer schon seit DOS. Die Laufwerkssubstituierung wirkt für das gesamte Filesystem und wird von Compilern berücksichtigt. Lediglich für bestimmte Tools (MSI-Installer) kann man es nicht verwenden. Das ist der Stand unter Windows-10.

Es gibt eine begrenzte Anzahl freier Laufwerksbuchstaben, die unterschiedlich sind auf verschiedenen Systemen je nach Nutzer-Vorliebe. Anbieten würden sich A: und B: da kaum jemand eine Diskette benutzt und die erste Festplatte immer noch auf C: liegt. Ungünstig ist Z:, dies wird bei VMware standardgemäß belegt.

Da auch andere Tools (auch Compiler) intern aus gleichen Gründen auch substuieren, benutzen diese auch gern B: als Laufwerksbuchstaben. Man muss also damit rechnen, dass das ausgewählte laufwerk, B: belegt ist, je nach verwendetem Tool. Das macht das Ganze zwar etwas unsicher, aber immerhin testbar in bestimmten Umgebungen möglich.

Um der Belegung des Laufwerkes B: von Tools aus dem Weg zu gehen, kann man einen dazwischenliegenden Buchstaben verwenden, der häufig noch frei ist. Das Problem dabei ist, dass das bei allen Bearbeitern zutreffen muss, sonst muss man wieder anpassen und ändern. Diese Bedingungen hat uns allerdings Microsoft-Windows aufdiktiert, es hat niemals die bewährte Methodik der Symbolic Links dem Anwender bereitgestellt. Es gibt beispielsweise eine Beschreibung https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createsymboliclinka, die aber anscheinend nur innerhalb von Programmen gilt, es ist eine Beschreibung einer Windows-API-Schnittstelle.

-------------------------------------------------

Im Zusammenhang mit dem Folgekapitel, Komponenten auf verschiedenen absoluten Pfaden im Projekt, die dann nicht mehr per Laufwerks-Ersetzung adressierbar sind, ist also die Variante B) mit Toolunterstützung zweckmäßiger.


6 Hard links und symbolic links im Windows-Betriebssystem

Topic:.EclipseWrk.hlink.

In Unix gibt es die Hardlinks und symbolic links von je her. Im Windows sind Hardlinks mit dem NTFS-Verzeichnissystem ebenfalls möglich, kaum dokumentiert und kaum jemand weiß es:

>fsutil hardlink create src/test.c ../src/TestString_emC.c

Dieser cmdline-Befehl (mit admin-Rechten) erzeugt das File src/test.c ab dem currdir als Hardlink zum vorhanden File ../src/TestString_emC.c. Man darf sogar den slash statt dem Backslash verwenden! mit Backslash im cmd geht es freilich genauso. Das Beispiel geht mit allen Files, sie müssen aber auf dem selben Datenträger stehen.

Was ist ein Hardlink? Ändert man im Beispiel src/test.c dann ist gleichzeitig ../src/TestString.c mit geändert. Nicht etwa weil die Änderungen irgendwie (per Zauberei) auf das andere File übertragen werden, sondern weil sich die Daten des Files auf dem selben Platz befinden, es also nur einmal Daten des Files gibt. Die Namen (Einträge im Directory) gibt es zwei mal, aber der eigentliche Speicherplatz des Fileinhaltes ist der selbe. Damit ist klar, dass die eine Datei (= der selbe Speicherplatz über den einen Verzeichniseintrag) sich sofort auch auf die andere Datei (selber Speicherplatz über einen anderen Verzeichniseintrag) auswirkt. Da die Verzeichniseinträge und der eigentliche Speicherplatz für den Fileinhalt eine Sache des selben Datenträgers sind, sind Hardlinks selbstverständlich nur auf dem selben Datenträger wirksam (Hinweis: nicht der "gleiche" sondern "ein und derselbe").

Diese Möglichkeit kann man nun nutzen, um Files einzurichten die im lokalen Workind-Directory stehen, ohne wie im Vorkapitel beschrieben über die Advances-Möglichkeit zu gehen und die Links im Eclipse zu organisieren.

Dennoch ist es ggf. günstiger über "Advanced" und den Link in Eclipse zu gehen weil dies besser kontrollierbar ist. Einem File (-Eintrag im Directory) sieht man nicht an dass er einen Zweitzugriff über einen anderen File(-Eintrag im Directory) hat, das ist also weniger durchschaubar als ein Link im Eclipse.

Auch die Softlinks funktionieren in Windows. Diese sind bekannt als *.lnk-File, beispielsweise zur Umleitung des Verzeichnisses C:/Programme auf C:/Program Files für die deutsche Windows-Version. Die Frage ist, ob der Symbolic-Link dieser Art verwendet werden kann direkt im Filesystem. Mindestens unter Visual Studio Code funktioniert dies:

d:\vishia\emcTest\TestString_emC\VScode>mklink /J src\emC\Base d:\vishia\emC\Base
Verbindung erstellt für src\emC\Base <<===>> d:\vishia\emC\Base

Mit diesem Befehlt wurde ab dem Arbeitsverzeichnis im vorhanden Subdirectory src/emC ein File Base.lnk erstellt, in dem die genannte Referenzierung auf den Absolutpfad steht. Die Dateien erscheinen im Visual Studio Code wie ganz normale Files. Auch hier gilt: Änderung dieser Files betreffen das Original. Der Vorteil von Symbolic Links ist: Sie sind im Filesystem erkennbar.

Auch im Eclipse kann man damit beispielsweise den Bin-Ordner auf die RAM-Disk umlegen und dabei das Projekt auf der regulären Festplatte stehen lassen, entgegen den Ausführungen in Chapter: 4 Das Eclipse-Projekt auf der RAM-Disk. Dass dies so einfach möglich ist, ist kaum irgendwo beschrieben.

Ein zip vom gesamten Ordner mit lnk-Subordnern erfasst die verlinkten Subordner so als ob sie kein Link sondern direkt wären (getestet mit Zip im Total Commander). Das hat den Nachteil, dass ein Auslagern von viel temporären Files nun doch wieder nicht gelingt, aber man kann ein Zipfile mit entsprechenden Cmd-Aufrufen auch gezielt so erstellen, dass nur bestimmte Files aus einem Subordner in das Zip gelangen

Hard- und Softlinks existieren im Betriebssystem UNIX seit Anfang an. Hardlinks sind eine natürliche Erscheinungsform, zwei Verzeichniseinträge zeigen einfach mal auf die selbe Section auf der Festplatte. Das hat mit der Organisation der Festplatten-Verzeichnisstruktur zu tun, die in UNIX von vornherein so angelegt ist. Soft-Links sind dagegen in UNIX eine Sonderkonstruktion, die seinerzeit wünschenswert war weil es die Hardlinks gibt und weil UNIX immer schon eine feste Struktur der Verzeichnisse hatte, nur ein Verzeichnisbaum ab der Root und keine Laufwerke, und somit das Mounten weiterer Datenträger bzw. die freie Umleitbarkeit der Zugriffe über Softlinks erfolgte. Systemprogrammierer unter UNIX (und später Linux) können damit umgehen.

DOS und Windows in der Anfangszeit war dagegen basierend auf dem CPM-Filesystem (FAT16, FAT32) aus den 80-ger Jahren nicht mit diesen Features ausgestattet. Wann genau das NTFS-Filesystem auch Hard-links beherrschte ist dem Verfasser im Moment nicht bekannt. Die Softlinks (*.lnk-Files) sind dagegen wahrscheinlich jedem Windows-Nutzer bekannt. Ob und seit wann der Filezugriff über die Windows-API-Filefunktionen, also von jedem Programm nutzbar, die Softlinks nutzen kann, ist dem Verfasser im Moment ebenfalls nicht bekannt. Jedenfalls scheint es unter Windows-10 zu funktionieren.

Die breite Nutzung von Hardlinks und Softlinks für diverse Directories ist im Windows aber nicht so sehr geläufig. Offensichtlich ist nirgends beschrieben, dass sich das bin-Verzeichnis recht einfach auf eine RAM-Disk umleiten lässt. Man muss solche Nutzungen daher gut dokumentieren und erklären, da sie für andere Nutzer irretierend sein könnten.


7 Die Crux mit den vergessenen Libraries, Denken in Komponenten

Topic:.EclipseWrk.extCmpn.

Wenn man sich in Sicherheit wiegt, dass man alle Files doch in einem Workspace relativ innerhalb Eclipse gespeichert hat, später oder auf einem anderen Rechner das Projekt aus dem Archiv holt und dann compiliert, dann kann es sein dass es Detailprobleme gibt.

Libraries werden oft aus dem Tool-Pool dazugelinkt, indem sie im Projektfile eingezogen werden. Wenn eine andere Toolversion installiert ist, andere Prozessoren im Embedded-C-Bereich unterstützt oder eben nicht unterstützt werden, Details mit der Zeit etwas anders geworden sind, dann wird dies ggf. erst bei Testen festgestellt, oder beim Compilieren fehlen die Libraries.

Häufig gibt es automatische Updating-Möglichkeiten, die die fehlenden Informationen aus dem Internet ergänzen. Ist das gut so? Sind Informationen mal schnell aus dem Internet geholt immer richtig. Solange man nicht extrem sicherheitskritische Dinge tut, ist es zumal der schnelle Schritt. Die Wahrscheinlichkeit, in eine Sicherheitsfalle zu tappen, ist zwar >0, aber meist passiert das nicht.

Was läuft falsch? Libraries die extern zugelinkt werden gehören genau so zu den Sources eines Produkts wie Quellen. Sie gehören folglich in die projektspezifische Versionierung. Es muss jederzeit möglich sein, aus den versionierten Quellen das Produkt zu erzeugen, gegenzuchecken auf Unveränderbarkeit, um es danach wie notwendig zu korrigieren!

Was sind eigentlich Libraries? Sie erscheinen als etwas gegebenes, fremdes, wofür der Lieferant gerade stehen muss. Diese Denkweise wird aber falsch, wenn man bedenkt, dass letztlich nur das Entwicklerteam für das jeweilige Produkt garantieren kann. Einen Fremdlieferant zur Verantwortung zu ziehen ist zwar juristisch möglich, aber dann gibt es meist bereits einen Schadensfall.

Libraries sind auch nur Sources, die vorcompiliert sind und in dieser Form als Libraries gebündelt.

Es gibt folgende Fragestellungen:

Eine Software besteht aus Komponenten:

Nur die Sources nach e) sind projektspezifisch und können nach entsprechender Qualifizierung (müssen allgemeingültig sein) teils zu den Sources f) kommutieren.

Bei den Sources nach f) ist es eben nicht angeraten, diese in das Projekt zu kopieren und danach projektspezifisch anzupassen. Damit sind sie nicht mehr allgemeingültig, die Wiederverwendung ist gebrochen. Von einer Wiederverwendung sollte nur gesprochen werden, wenn eine unveränderte Wiederverwendung möglich ist bzw. Änderungen für eine weitere (verbesserte) Wiederverwendung gebrauchsfähig sind und die geänderten Sources nach f) auch in den ursprünglichen Projekten wieder direkt eingesetzt werden können.

Folglich sind die Sources nach f) teils als eingezogene Libraries betrachtbar. Gleiches gilt für Sources nach h).

Es ergibt sich nunmehr die Fragestellung:

Eine Library ist die Zusammenstellung vorübersetzter Sources

Nun kann es inbesondere typisch sein, dass die wiederverwendeten Sources gleichzeitig in verschiedenen Projekten am selben PC eingesetzt werden, eben weil bei deren Verbesserung zeitnah oder 'gleich mit' getestet werden soll, ob die Änderungen gut sind:

Eben aus diesem Grund (der sofort einbezogenen Tests) ist es nicht günstig, die Sources jedes mal über checkin/commit in das Revisionsmanagement zu führen oder zwischen Working spaces zu kopieren, sondern sofort unverzüglich mit jeder Änderung in dem anderen Projekt zu testen.

Das spricht für entweder absolute Pfade zu den Speicherorten dieser Komponenten-Sources, oder mindestens für relative Pfade mit ../.., wenn die anderen Projekte ebenfalls relativ danebenstehend angeordnet sind.

Folglich muss in den Projektfiles (in Eclipse, in Visual Studio etc.) es eine Anpassmöglichkeit der Speicherorte komponentenweise geben. Das ist die Variante B) im Vorabschnitt.


8 Eindeutige Pfadangaben zu Komponenten-Files

Topic:.EclipseWrk.pkg.

In Java ist es gängige Praxis, Sources in Packages anzuordnen. Packages sind auf Fileebene eine Subdirectory-Struktur. Die Packages fangen üblicherweise mit der umgekehrten URL (www-Adresse) an, damit werden Name-clashes weltweit verhindert. Das ist ein Quasistandard, an den sich an sich jeder hält. Packages der Standard-Java-Sources beginnen beispielsweise mit com.sun.awt obwohl diese Files schon längst von Oracle geändert worden sind (Oracle hatte Sun im Jahre 2010 übernommen). Die Package-Bezeichnung bleibt. Eigene Packages sollten diesem Schema ebenfalls entsprechen.

In C/C++ ist dieses Schema ebenfalls anwendbar, aber leider nicht verbreitet. Dies ist ein Plädoyer für dessen Verwendung:

Diese Schreibweise des Include mit package-path ist in C seit Anfangszeiten möglich aber wenig genutzt. Er wird von allen Compilern unterstützt. Man muss es nur tun.

Vorteil: Verhinderung von name-Clashs

Nachteil: Ein gewisser Zwang sich nach etwas zu richten was man zunächst gar nicht einsehen möge.

Diese Schreibweise ermöglicht aber nun die eindeutige Anpassung von Projektfiles an die Speicherorte von Komponenten mit absoluten Pfaden.

Persönliche Anmerkung: Der konsequenten Anwendung des Package-Path-Prinzips aus Java für C/++ habe ich mich auch erst schrittweise genähert. Ich hätte sie seit 15 Jahren schon umsetzen können. Da dies im C/++-Bereich aber überhaupt nicht üblich ist, obwohl es problemlos geht, war auch ich inkonsequent. Auch jetzt ist es noch inkosequent, da die Packages meiner Sources mit org/vishia anfangen müssten, nicht nur mit vishia. Dazu wäre aber im Filesystem einiges umzuschieben. Daher lasse ich das org weg, in der Hoffnung das es keine andere Seite im fernen Indien, China oder sonstwo gibt die ebenfalls mit vishia beginnt. org/vishia ist insofern eindeutig, da dies meine Internetadresse weltweit registriert ist.

TODO Kleines Minitool für Adaption, Beispiel.