Hallo,
gibt es eine Möglichkeit, die SW-Versionsnummer automatisch beim
Compilieren/Linken in den Quellcode zu bekommen, so dass man jederzeit
die Version und/oder Build-Nummer abfragen kann?
Entwickelt wird die SW derzeit noch mit CooCox 1.7.8, aber ein Kollege
und ich wollen das umstellen auf Eclipse.
Was genial wäre, ist z. B. ein automatisch erzugtes Headerfile mit dem
Inhalt
1
#define BUILD 621
Wenn man dann die SW-Version abfragt, bekommt man z. b. die Meldung
Version XYZ, Build 621
Wird neu compiliert, egal ob was geändert wurde oder nicht, geht die
Buildnummer automatisch um eins höher.
Vllt. gibt es ja sowas wie ein Plug-In oder andere Möglichkeiten.
Was könnte denn ein sinnvoller Nutzen davon sein? Solange man keine
Zuordnung von Buildnummer zu Quellcodeversion hat?
Ich meine diese Frage nicht provokant, ich möchte nur wissen warum man
sowas tut. Mir fällt gerade auf die schnelle nichts ein.
Wir haben zum Beispiel ein Makefile, dass vor dem Compileraufruf diverse
Sachen aus dem Mercurial Repository abfragt. Wenn der aktuell
kompilierte Commit einen Versionstag hat, wird dieser mit in die
Software gebaut.
K. H. schrieb:> Wird neu compiliert, egal ob was geändert wurde oder nicht, geht die> Buildnummer automatisch um eins höher.
Sehr unschöner Ansatz. Deutlich besser wäre es, die
Build-/Versionsnummer wirklich nur dann hochzuzählen, wenn etwas am Code
geändert wurde.
Vgl. auch z. B. https://reproducible-builds.org/ - sprich, Ziel sollte
immer sein, mit "gleicher" Codebasis und identischer Toolchain
identische Binärdateien zu erhalten.
Bei SVN gibt es z. B. die Variablen für die Commit-Nummer, die sich in
die Quelldateien einbinden lassen - würde auf einem solchen Ansatz
aufbauen (z. B. GIT-Hash oder je nach eingesetzter Versionsverwaltung).
Einem Build muss man irgendwie eine bestimmte Codebasis, sprich, eine
Versionsverwaltung-Revisionsnummer eindeutig zuordnen können, sonst ist
das witzlos.
Ein fortlaufender Zähler ermöglicht dies nicht, außer du pflegst
händisch irgendeine Tabelle.
Ich würd also irgendwie schauen dass ich die Werte aus der
Versionsverwaltung in den Quelltext bekommen.
svn kann das wie erwähnt recht gut.
Ansonsten könne man Makros für Buildzeit und Builddatum benutzen (gcc
kann das z.B.) wenn zwei Builds mit identischer Codebasis trotzdem
unterscheidbar sein sollen.
Christopher B. schrieb:> Was könnte denn ein sinnvoller Nutzen davon sein? Solange man keine> Zuordnung von Buildnummer zu Quellcodeversion hat?
Die Sache ist die, dass wir mit vllt. 3 Leuten Firmware bauen und wir
wollen eigentlich nur wissen, welche Firmware auf welchem Board ist und
ob es evtl. geupdated werden muss. Ob jetzt hinter Build #326 xyz steht
oder ABC ist dabei egal. Es geht im Grunde nur darum, welche Version ist
derzeit drauf.
Toni Tester schrieb:> Sehr unschöner Ansatz. Deutlich besser wäre es, die> Build-/Versionsnummer wirklich nur dann hochzuzählen, wenn etwas am Code> geändert wurde.
Sowas können wir später vllt. einmal machen, jetzt geht es darum, die
ersten Produkte zu verkaufen. Ich arbeite bei einem Start-Up und da ist
halt vieles erstmal nebensächlich aber eine Grundordnung sollte schon da
sein.
Le X. schrieb:> Ein fortlaufender Zähler ermöglicht dies nicht, außer du pflegst> händisch irgendeine Tabelle.
Genauso machen wir bzw. ich es gerade. Irgendwo am Anfang von main()
steht sowas und man muss das manuell machen und wer ändert das schon?
Das Problem dabei ist, wir haben eine Codebasis, die für mehrere
Teilprojekte ist. Wenn einer was an der Codebasis ändert, weiß ich evtl.
davon und kann dann ein Update machen, kann aber auch sein, dass die
Änderungen mein Teilprojekt überhaupt nicht betrifft. Und es müssen bei
der Sache alle mitspielen.
Ein anderes Problem bzgl. GIT ist, dass wir manchmal kein Internet
haben, denn alle unsere Software liegt auf Github privat. Von daher
würde ich auf weitere Internetaktivitäten gerne verzichten, mir reicht
schon Google-Drive, Trello und Standard-Git.
K. H. schrieb:> Die Sache ist die, dass wir mit vllt. 3 Leuten Firmware bauen und wir> wollen eigentlich nur wissen, welche Firmware auf welchem Board ist und> ob es evtl. geupdated werden muss.
Mach doch einfach eine CRC-32 über die Firmware beim Build, die dann
auch im Produkt abfragbar ist. Damit kannst Du erstens die Integrität
der Firmware prüfen, also ob der Upload korrekt funktioniert hat, und Du
hast Änderungen daran nur dann, wenn sich auch was im Binary geändert
hat (also nicht nur Umbenennung von Defines).
Nop schrieb:> Mach doch einfach eine CRC-32 über die Firmware beim Build, die dann> auch im Produkt abfragbar ist.
Das machen wir beim Bootloader, allerdings kann man anhand eines
CRC-Checksumme nicht feststellen, ob die eine Version neuer ist als die
andere.
K. H. schrieb:> Das machen wir beim Bootloader, allerdings kann man anhand eines> CRC-Checksumme nicht feststellen, ob die eine Version neuer ist als die> andere.
Zum einen mußt Du ja eh eine Liste führen, zum anderen könntest Du aber
auch über die C-Makros _DATE__ und __TIME_ im Quellcode arbeiten. Aber
das hat, genau wie der Build-Zähler, den entscheidenden Nachteil, daß
die Builds nicht mehr reproduzierbar sind.
K. H. schrieb:> Die Sache ist die, dass wir mit vllt. 3 Leuten Firmware bauen und wir> wollen eigentlich nur wissen, welche Firmware auf welchem Board ist und> ob es evtl. geupdated werden muss. Ob jetzt hinter Build #326 xyz steht> oder ABC ist dabei egal. Es geht im Grunde nur darum, welche Version ist> derzeit drauf.
Und wie sorgst du dafür, dass alle drei den selben Zähler für die
Build-Nummern benutzen? Oder müssen alle drei immer am selben Rechner
arbeiten?
Nop schrieb:> argh..
Du kannst es auch kursiv machen, denn das lässt sich nicht mit
unterstreichen kombinieren: __DATE__ und __TIME__
Rolf M. schrieb:
> Und wie sorgst du dafür, dass alle drei den selben Zähler für die> Build-Nummern benutzen?
Per NTP oder notfalls per GPS :)
> Oder müssen alle drei immer am selben Rechner arbeiten?
Build-Server?
Aber im Ernst, kann man nicht einfach die Unix-Sekunden als Build-Nr.
benutzen? Mit dem Datum der neuesten Quell-Datei in der Variablen
SOURCE_DATE_EPOCH ist das doch gleichzeitig ein Schritt in Richtung
https://reproducible-builds.org/
Danke dafür, Toni Tester!
Thread beobachten
Seitenaufteilung abschalten