SNV C++ Projekt Managment

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.

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

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

#define MCU AVR128DB64

vor allem weiteren include-directiven.

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.

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

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.

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.

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

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

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.

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.