Forum: Compiler & IDEs SNV C++ Projekt Managment


von Joachim J. (felidae)


Lesenswert?

HI @ all,

Ich verwalte mein C++ Code in einem SVN(Subversion). Ich habe dort eine 
Art Bibliotek mit Modulen die ich in verschiedenen Projekten verwende. 
Wenn ich ein C++ Projekt für einen Controller x erstelle, lade ich die 
Module für Controller x aus meiner Bibliotek mit Hilfe der SVN Property 
externels. Das Funktioniert sehr gut. Wenn ich das Modul verbessere, 
landet der neue Code automatisch in allen meinen Projekten. Dann muss 
ich den Code nicht von Hand überall einpflegen.

Jetzt habe ich über die Jahre aber schon so viele Module geschrieben. 
Wenn ich eine neues Projekt anlege, brauche ich ewig dem Compiler zu 
sagen welche Module ich alles nicht mit Compiler will, weil ich die in 
diesem Projekt nicht brauche. Ich suche jetzt eine Lösung wie ich das 
besser managen kann.

Beim Linux Kernel hat man das Gleiche Problem. Dort gibt es daher die 
Funktion "make menuconfig". Damit öffnete man ein Kernel Config menu, wo 
man einzelne Module und sogar ganze Gruppen von Modulen vom Compiler aus 
schlissen kann. Am ende erstellt man dann mit "make Config" das 
makefile.

Genau das bräuchte ich für meine Projekte. Gibt es irgendwo eine 
Anleitung wie man das für ein eigenes Projekt erstellt? ich finde immer 
nur Anleitungen, wie man das Config Menu beim linux kernel benutzt oder 
um einzelne Einträge erweitert. Gibt es vielleicht eine andere Lösung 
die auch praktikabel ist? ich bin für Vorschläge offen.

von Vincent H. (vinci)


Lesenswert?

Ich kenn mich mit SVN leider nicht aus, aber ich vermute da geht es um 
irgendein Textfile wo die Abhängigkeiten halt gelistet sind? Bist du 
sicher dass du da mit menuconfig schneller wärst...?

Die ursprüngliche Logik dass du Module explizit ausnehmen musst find ich 
etwas seltsam. Normalerweise gibt man explizit an welche Abhängigkeiten 
ein Projekt benötigt, nicht umgekehrt.

von A. B. (funky)


Lesenswert?

ich vermute alle Moduel liegen in EINEM Repo und dann muss manuell 
gefummelt werden

von Wilhelm M. (wimalopaan)


Lesenswert?

Dein Repo mit der Lib sollte alles enthalten. In einem uC Projekt machst 
Du einfach nur:

#define MCU AVR128DB64

vor allem weiteren include-directiven.

von Joachim J. (felidae)


Lesenswert?

A. B. schrieb:
> ich vermute alle Moduel liegen in EINEM Repo und dann muss manuell
> gefummelt werden

Das ist richtig. Ich habe einen scr Ordner. Alles was da drin ist wird 
von der IDE Compiliert. Ich lade die Module aus der Bibliothek via 
externel in das Projekt und der Compiler versucht erst mal alles zu 
Compilieren. Einige Module werfen aber Fehler, wenn man sie nicht im 
Projekt(in der Main.c) mit   Variabeln initialisiert. Ich muss jetzt 
immerm, für jedes Modul das ich nicht brauche, alle .cpp File mit 
"exclude fom build" raus werfen damit es nicht zu Fehler beim 
Compilieren kommt. das war am Anfang noch Praktikable.
Jetzt sitze ich aber fast 20min bis ich alles fertig habe.

von Vincent H. (vinci)


Lesenswert?

Für den Anfang würde es wohl schon mal reichen die Logik umzudrehen. 
Meiner Meinung nach sollte per Default gar nichts inkludiert werden, 
nicht einfach alles. Dass manche deiner Bibliotheken ohne 
Nutzer-definierte Variablen Compilerfehler erzeugen ist wohl auch ein 
Designschnitzer und wenn hoffentlich sehr gut dokumentiert. ;)

von Rolf M. (rmagnus)


Lesenswert?

Bei SVN muss man nicht immer das ganze Repo auschecken. Man kann auch 
nue´r einzelne Unterverzeichnisse auschecken und auch als external 
verlinken. Du könntest also für jedes benötigte Modul ein eigenes 
external anlegen. Dann hast du nur die Module, die für das Projekt 
gebraucht werden.

von Walter T. (nicolas)


Lesenswert?

Joachim J. schrieb:
> Wenn ich ein C++ Projekt für einen Controller x erstelle, lade ich die
> Module für Controller x aus meiner Bibliotek mit Hilfe der SVN Property
> externels. Das Funktioniert sehr gut

Die Frage ist: Seit wann?

Früher habe ich das auch gemacht, heute nicht mehr. Das Problem ist, 
dass es viel Aufwand gekostet hat, alte Builds reproduzierbar 
wiederherzustellen oder Module zu ändern und gleichzeitig kompatibel zu 
halten.

Das war es mir irgendwann dann nicht mehr wert.

Das liegt aber vielleicht auch daran, daß meine Projekte eher Fire & 
Forget sind und nicht jahrelang kleinteilig gewartet werden. Nach X 
Jahren ist entweder eine komplette Revision oder eine winzige 
Fehlerkorrektur fällig, ständige winzige Verbesserungen habe ich 
eigentlich nie.

von Μαtthias W. (matthias) Benutzerseite


Lesenswert?

Hi

Und wenn du tatsächlich das Zeug aus dem Linuxkernel verwenden willst 
ist hier https://www.kernel.org/doc/html/v5.3/kbuild/index.html der 
richtige Einstiegspunkt dafür. Für ein µC Projekt halte ich das aber für 
Kanonen auf Spatzen.

Matthias

von Joachim J. (felidae)


Lesenswert?

Danke für die Tipps und den Link. ich werde das mal alles durchdenken 
uns mal schauen was da raus kommt.

von T.U.Darmstadt (Gast)


Lesenswert?

Joachim J. schrieb:
> Ich suche jetzt eine Lösung wie ich das
> besser managen kann.
Weniger Abhängigkeiten zwischen Moduln. Ich kopiere mir die Codes 
manuell, passe sie an und notiere das in einer Liste, die beschreibt, 
was das neue Modul kann und gfs mehr kann. Nur bei Bedarf kriecht dann 
ein aktualisiertes in ein neues Projekt.

Ansonsten geschlossene Landschaft in jedem Projekt.
Soviel gibt es da nicht zu aktualisieren, wenn man getestete (also 
funktionierende) SW ausliefert.

von Vincent H. (vinci)


Lesenswert?

Thomas U. schrieb:
> Joachim J. schrieb:
>> Ich suche jetzt eine Lösung wie ich das
>> besser managen kann.
> Weniger Abhängigkeiten zwischen Moduln. Ich kopiere mir die Codes
> manuell, passe sie an und notiere das in einer Liste, die beschreibt,
> was das neue Modul kann und gfs mehr kann. Nur bei Bedarf kriecht dann
> ein aktualisiertes in ein neues Projekt.
>
> Ansonsten geschlossene Landschaft in jedem Projekt.
> Soviel gibt es da nicht zu aktualisieren, wenn man getestete (also
> funktionierende) SW ausliefert.

Das widerspricht in so ziemlich allen Belangen den "best practices" 
moderner Software Entwicklung.

Stell dir mal vor du hast die letzten 20 Jahre ein Frontend in 
verschiedenen Variationen ausgeliefert und lustig Code copy/pasted. 
Eines Freitag Abend schickt dir der Support eines Kunden eine 
Vulnerabilität die umgehend gefixt werden muss und du fängst an jedes 
alte Projekt anzufassen um das dort anzupassen. Mit viel Glück hast du 
dann Montag noch einen Job.

von Walter T. (nicolas)


Lesenswert?

Vincent H. schrieb:
> Das widerspricht in so ziemlich allen Belangen den "best practices"
> moderner Software Entwicklung.

Stimmt schon - wenn unter "moderner" Software alles verstanden wird, was 
irgendwie ans Internet angebunden wird.

Standalone-Geräte können auch gerne mal mit ihrer ersten 
Firmware-Revision von der ersten Auslieferung bis zur Verschrottung ein 
paar Jahrzehnte später klarkommen.

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.