Forum: PC-Programmierung Versionsverwaltung: zwei Branches parallel führen?


von Karl (Gast)


Lesenswert?

Tag zusammen,

ich habe ein AVR Projekt, dass ich mittels git verwalte. An dem Projekt 
arbeiten neben mir noch zwei andere Entwickler.
Momentan arbeiten wir alle mit einer Testhardware mit "großem" 
ATmega1284P Controller. Auf dem Board werden alle Controllerpins 
rausgeführt, außerdem ist ein LCD zum Testen angeschlossen. Die zweite 
UART wird zum Debuggen benutzt.

Nun ssteht bald der Schritt hin zur realen Hardware auf dem 
Programm.Dabei handelt es sich um eine extra angefertige Platine, auf 
der ein kleinerer Mega32 sitzt und auf dem nur die wirklich benötigten 
Pins benutzt werden. Auf einen Quarz wird verzichtet.

So, das resultiert natürlich in einer angepassten Software.
Registernamen werden sich ändern, Pinbelegungen ändern sich, 
Konfigurationen ändern sich, manche Module fliegen ganz raus (zweite 
UART, LCD).

Die Frage ist nun, wie ich diesen Vorgang in git (oder generell, in 
einer Versionsverwaltung) abbilde.
Mein erster Gedanke war, vor dem "Cut" alle offenen Branches in den 
master zurückzuführen, dass die Software erstmal komplett ist. Danach 
würde ich zwei Branches separat weiterlaufen lassen, einmal für den m128 
und einmal für den m32. Hintergrund ist, dass unsre Testhardware 
weiterhin zum Entwickeln/Bugfixing genutzt werden soll.

Allerdings bin ich mir nicht sicher ob das so passt. Ich müsste ja 
regelmäsig die Branches mergen. Dabei allerdings dann per Hand 
kontrollieren dass kein Controllerspezifisches Zeugs, wie Registernamen, 
gemergt wird. Das wird umständlich.

Wie würdet ihr das handhaben?
Was hat sich da bewährt?

von Thorsten O. (Firma: mechapro GmbH) (ostermann) Benutzerseite


Lesenswert?

Warum machst du nicht einfach je eine Controller-spezifische 
Konfigurationsdatei bzw. Config-Funktion? Dann kann du mittels DEFINE 
(oder im Makefile) festlegen, für welchen Controller du compilieren 
willst.

Mit freundlichen Grüßen
Thorsten Ostermann

von Kai S. (zigzeg)


Lesenswert?

Ich wuerde per defines zwischen den Versionen umschalten.
Es gibt dann Builds fuer beide Targets die die passenden defines setzen.

von Mark B. (markbrandis)


Lesenswert?

Karl schrieb:
> Die Frage ist nun, wie ich diesen Vorgang in git (oder generell, in
> einer Versionsverwaltung) abbilde.

Wie wär's mit "gar nicht"? ;-)

Sourcecode kann für unterschiedliche Zielhardware übersetzt werden, das 
ist durchaus üblich so. Für die Verwaltung der Quelltexte an sich hat 
das keine wirkliche Auswirkung. Vielleicht mal abgesehen von einer 
Konfig-Datei oder den Makefiles, die man anpassen muss. Diese liegen 
natürlich auch im Repository.

von Karl (Gast)


Lesenswert?

Das ist eigentlich nicht die schlechteste Idee :-)

Allerdings muss ich mir dazu wohl noch Gedanken machen, denn in einer 
#IFDEF Schlacht soll das Ganze nicht ausarten. Vor allem 
Funktionsaufrufe zu Test/Debuggfunktionen müssen aber irgendwie 
geschützt werden.

von Ingo K. (unseen)


Lesenswert?

Karl schrieb:

> Allerdings muss ich mir dazu wohl noch Gedanken machen, denn in einer
> #IFDEF Schlacht soll das Ganze nicht ausarten. Vor allem
> Funktionsaufrufe zu Test/Debuggfunktionen müssen aber irgendwie
> geschützt werden.

Dafür gibts diverse Möglichkeiten - ich beschränke z.B. die #ifdefs 
gerne auf die Headerdatei, in der dann je nach Konfiguration entweder 
die echten Funktionen deklariert oder Dummydefinitionen erzeugt werden. 
Zusätzlich sorgt das Makefile dafür, dass die zugehörige C-Datei mit den 
Funktionsdefinitionen nur eingebunden wird wenn die Konfiguration sie 
benötigt.
1
#ifdef CONFIG_UART_DEBUG
2
3
void uart_init(void);
4
void uart_putc(char c);
5
6
#else
7
8
#define uart_init()    do {} while(0)
9
#define uart_putc(x)   do {} while(0)
10
11
#endif

Statt der Leermakro-Definition könnte man auch "static inline void 
uart_init(void) {}" im Headerfile verwenden, der Compiler sollte dann 
den Aufruf der leeren Funktion komplett rausoptimieren. Welche Variante 
man für weniger böse hält hängt auch von den lokalen Code-Richtlinien 
ab, wahrscheinlich gibts da auch welche die beide davon verbieten 
würden.

von Hans (Gast)


Lesenswert?

Du kannst das Define auch einfach leer lassen:
1
#ifdef CONFIG_UART_DEBUG
2
3
void uart_init(void);
4
void uart_putc(char c);
5
6
#else
7
8
#define uart_init()
9
#define uart_putc(x)
10
11
#endif

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.