Frage: Software Code ohne Version/Revision dokumentieren

[Siro]

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

[shedepe]

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.

[Siro]

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:

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

[White_Fox]

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

Andere schämen sich da durchaus für.

Dir auch ein schönes Wochenende.

[Klebwax]

....
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

[PICture]

Hallo!

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.