Frage: Software Code ohne Version/Revision dokumentieren

Mir ist eben bei der Dokumentation meiner Microchip PIC Software aufgefallen,
dass es etliche von Source Code Dateien von Microchip gibt, die keine Version / Revisionsnr haben, nichts...

Beispiel: Die Datei

pic.h oder auch die xc.h

Da sie unterschiedliche Dateigrößen in unterschiedlichen Versionen haben, werden sie sich vermutlich auch unterscheiden
ich hab den Code aber nicht komplett verglichen.

Es befindet sich in den Dateien leider kein Hinweis auf eine Version Revision oder Zugehörigkeit, leider garnichts.

Da ich ALLE benötigten Dateinen meines Projekt mit einer Versionsnummer/Revisionsnr grade aufliste,
fällt das jetzt etwas schwer mit der Dokumentation.

Idee: Ich werde nun die benötigten Dateien in meinen Projektordner kopieren müssen
und mit einem Editor eine Version/Revisionsnr vergeben müssen.

Wie macht man das denn am Besten ?
Ich wollte jetzt eigentlich nicht in der ohnehin schon als "SOUP" deklarierten Software auch noch Änderungen vornehmen müssen.

Oder ich schreibe die Dateien komplett neu, bzw. specke sie ab für mein Projekt. Dann ist es auch keine SOUP mehr.

Bei den eigentlichen Include Files der PICs z.B. Pic12F1840.inc
hat man es aber gemacht:
// Version 2.05
// Generated 20/12/2018 GMT
warum nicht bei den anderen Dateien ?

Ohne jeglichen Texthinweis in einer Datei find ich schon etwas "armselig" Bild hier  

Siro

Anstatt von Hand Versionsnummer zu vergeben verwendet man heutzutage Versionsverwaltungssystem wie GIT oder SVN (Das nur mal als Hinweis zu deiner Idee von Hand Versionsnummern in deine Files zu schreiben - das würde ich echt nicht machen).

Zu deinem eigentlichen Problem: Das ist kein direktes Versionierungsproblem im Sinne einer klassischen Versionsverwaltung sondern eher eine Versionsverwaltung hinsichtlich der benötigten Umgebung.
Auch die PIC Toolchain wird eine bestimmte Versionsnummer haben. Unter den meisten Linux Distros wäre es z.B. sinnvoll die Version des installierten Pakets anzugeben, unter Windows eben die runtergeladene und installierte Version.
Bsp: Unter Python kann man ein requirements file für die Setuptools mit angeben, bei dem man die benötigte Version von Abhängigkeiten angeben kann.

Ersteinmal Danke für dein Info shedepe.

Da hast Du natürlich recht,
die besagten Dateien stammen aus einer "bestimmten" Version der Entwicklungstools.
In meinem Falle ist dies der Compiler XC8 in der Version 2.00 oder folgende.
Diese Dateien sind bei mir in den Ordnern:

C:\Programm\Microchip\XC8\V2.00
C:\Programm\Microchip\XC8\V2.05

dann in den Unterordnern:
...\PIC\include

Diese Zugehörigkeit lässt sich jedoch im Nachhinein, lediglich aus der Datei, nicht mehr erkennen,
das finde "ich" halt etwas schade, oder problematisch.
Hier würde ich mir schon wenigstens eine Zeile mit Info wünschen.
// XC8 Version 2.0 das reicht doch schon...

Die gesamte Archivierung von Projekten ist leider bei mir eine riesen Baustelle, wenn man das so nennen darf.
SVN und/oder GIT sind für mich böhmische Dörfer.
Ich hab da zwar schon Einiges drüber gelesen, aber ehrlich gesagt. "in meinem Falle" viel zu aufwendig.
Unsere Entwicklungsabteilung ist recht übersichtlich, denn das bin nur ich selbst.
Code sowie die Verwaltung dafür liegt also nur in meinen Händen.
Für größere Projekte an verteilten Orten usw, ist die Versionsverwaltung sicherlich unumgänglich,
brauchen wir nicht drüber zu diskutieren. Ja, ein MUSS auf jeden Fall.


Meine Versionsverwaltung sind lediglich die Software(Firmware) Versionen selbst.
V1.00 V1.12 usw.
entsprechend sieht auch meine Ordnerstruktur aus.
In den Ordnern findet man dann "ALLE" Dateien um ein erneutes, theoretisch identisches, Compilat wieder zu erzeugen.
Inzwischen weis ich aber, dass selbst das, kaum möglich ist aufgrund tonnenweiser Einstellungen
in den Compilern / IDEs Registryverwaltungen usw.
In meinen Augen ein fast aussichtsloses Unterfangen ohne Festplattenbackup.

Deshalb mein Anliegen, wenigstesn eine Kommenartzeile in "jeder" Datei für die Zugehörgkeit wäre schön.

Siro

Wie gesagt: Würde ich davon abraten. Dazu hat man eine Versionsverwaltung die Tags kann. In jedem File einzeln Versionen reinzuschreiben dauert lange und ist fehleranfällig. Außerdem ist es aufwendig z.B. einzelne Files zurückzusetzen.
Mein Tipp für deine eigene Software: Schau dir Git an: Kann man sogar ohne Server lokal verwenden und ist in den Basis funktionen jetzt wirklich nicht so schwierig zu verwenden:
Hauptsächlicher Ablauf: git add git commit git push

Mit git log und git blame kann man dann bis auf Zeilenebene Änderungen im Code nachvollziehen.
Aufwendig ist das halt nicht, sondern benötigt nur mal einen Tag Einarbeitungszeit. Danach hat man ein viel mächtigeres Werkzeug bei der Hand. (Wobei ich durchaus nachvollziehen kann, dass man sich manchmal sträubt doch was neues anzuschauen, wenn das bisherige Verfahren ja funktioniert)

Ansonsten bewegst du dich damit in den Bereich Continous Integration bzw. verifiable builds. Mein Tipp ist es außerdem darauf zu verzichten den Build durch eine IDE zu erzeugen sondern lieber durch ein Buildsystem wie Make oder CMake oder irgendwas anderes. Da kann man dann nämlich auf Versionen der Toolchains usw. prüfen und weiß defintiv mit welchen Einstellungen man kompiliert. Einen Schritt weiter könnte man gehen in dem man seine Entwicklungsumgebung in einem Container (z.B. Docker oder Systemd) aufsetzt und eben diesen Container versioniert. So wird das dann in großen Umgebungen gemacht: Leerer Container mit definierten Versionen von Tools, Code wird frisch aus dem Repo gecloned, Build wird gestartet, Build Ergebnisse eingesammelt.

So jetzt hab ich dir ganz schön viel an den Kopf geworfen:
Wenn du sagst: Das ist mir zu viel: Mein Vorschlag: Kopier die dir PIC library und schreib dir ein Skript was automatisch die Versionen von deinem Code in den Header der Files reinschreibt. Schön ist das zwar nicht und über Probleme dieses Vorgehens bist du dir vermutlich selbst bewusst, aber wäre denke ich eine schnelle Lösung.

Mahlzeit und vielen Dank nochmal an shedepe für deine Informationen und Mühe.
Mit dem Git muss ich mir wohl doch nochmal genauer anschauen.
Ich arbeite ja generell nur Lokal auf einem Rechner, das scheint mit Git auch möglich zu sein.

Ich müste mal versuchen ein Compilat ohne die IDE zu erzeugen, mittesl Makefiles
Linkerscript, das sollte ja auch irgendwie möglich sein.
Zumindest für die "Release" Version, dann brauche ich auch keine IDE archivieren, lediglich die Compiler.

In unserer Verfahrensanweisung steht:

Zitat:

---

SOUP Elemente einschließlich Standard-Bibliotheken müssen erfasst und entsprechende Informationen
zum Titel, Hersteller und SOUP-Kennung aufgezeichnet werden.

Die freigegebene Version der Software muss in der Liste der Konfigurationselemente aufgezeichnet werden.
Das Verfahren und die Umgebung, die verwendet wurden, um die freigegebene Software zu erzeugen,
muss dokumentiert werden.
.....

---

Der Papierkrieg überrolt mich grade und die Entwicklung steht, für eine Person wird das echt zu viel. ;)
Lehrgang IEC62304 hab ich auch hinter mir....

Und dann noch ackern, wo andere den Frauentag genießen :)
Ich wünsche euch allen ein schönes Wochenende.

Siro

Zitat:

---

Zitat von Siro

Und dann noch ackern, wo andere den Frauentag genießen :)

---

Andere schämen sich da durchaus für. ;)

Dir auch ein schönes Wochenende.

Zitat:

---

Zitat von Siro

....
pic.h oder auch die xc.h

Da sie unterschiedliche Dateigrößen in unterschiedlichen Versionen haben, werden sie sich vermutlich auch unterscheiden
ich hab den Code aber nicht komplett verglichen.

Es befindet sich in den Dateien leider kein Hinweis auf eine Version Revision oder Zugehörigkeit, leider garnichts.

Da ich ALLE benötigten Dateinen meines Projekt mit einer Versionsnummer/Revisionsnr grade aufliste,
fällt das jetzt etwas schwer mit der Dokumentation.

Idee: Ich werde nun die benötigten Dateien in meinen Projektordner kopieren müssen
und mit einem Editor eine Version/Revisionsnr vergeben müssen.
....

---

Das halte ich für keine gute Idee. xc.h z.B. wird in jedem File bei MPLABX angezogen. Dahinter verbirgt sich heftige Macro-Magie. Zusammen mit dem Prossortyp, der in den Projekteinstellungen festgehalten ist, werden die unterschiedlichsten weiteren Headerfiles angezogen. Ob das noch funktioniert, wenn diese Files nicht mehr an der alten Stelle im System liegen, bezweifle ich.

Und ob diese neu vergebene Versionsnummer reicht, müsste man auch klären. Sie ist von dir vergeben worden, niemand kann sie überprüfen, das Original hat ja keine. Jetzt hast du die ganze Verantwortung für die Toolchain mit all ihren Files an der Backe, da du ja was dran geändert hast.

Ich würde das anders angehen. In einer virtuellen Maschine (z.B. VMware oder Qemu) würde ich mir ein Minimalsystem einrichten, nur Betriebssystem, IDE, Compiler und andere benutzte Tools. In diesem wird gearbeitet. Und wenn man einen Stand abspeichern will, sichert man das Image. Das sollte selbst dann noch laufen, wenn eine neue Version des Host-Betriebssystems gängig ist. Heutzutage würde man dafür wohl Docker statt einer virtuellen Maschine verwenden. Ich muß aber zugeben, daß ich damit keine Erfahrung habe.

MfG Klebwax

Hallo!

Zitat:

---

Zitat von Klebwax

Das halte ich für keine gute Idee. xc.h z.B. wird in jedem File bei MPLABX angezogen. Dahinter verbirgt sich heftige Macro-Magie. Zusammen mit dem Prossortyp, der in den Projekteinstellungen festgehalten ist, werden die unterschiedlichsten weiteren Headerfiles angezogen. Ob das noch funktioniert, wenn diese Files nicht mehr an der alten Stelle im System liegen, bezweifle ich.

---

Ich kann das nur bestätigen. Wozu braucht man sinnlose Versionsnummern ? Ich habe das bisher nie gebraucht. :confused: