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.
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.
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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.