Guten Tag allerseits Solange man mit völlig verschiedenartigen Projekten arbeitet, hat man mit der Ordnung kein Problem: alle Dateien sind unter einem Ordner wohlbehütet aufgehoben. Sobald aber die Projekte Schnittpunkte aufweisen, ist Chaos vorprogrammiert. Denn man übernimmt ja nie stur ein Modul, ohne es durchzusehen, und diese und jene Kleinigkeit zu verbessern. Und nach ein paar Jahren hat man von demselbem Modul x-verschiedene Versionen. Deshalb arbeite ich mit Libraries. Klappt auch wunderbar. Nur muss ich beim Wechsel von einem Project zum anderen alle Bibliotheken nochmals compilieren. Weder vom Aufwand noch von der Zeit her ein Problem. Nur habe ich irgendwie das Gefühl, dass das, was ich mache, nicht das Gelbe vom Ei ist. Ich bin sicher, es gibt eine elegantere Lösüng. Was ich mache ist: Unter D:\Prg\MCU\Avr\WinAvr\avr\my_libs befinden sich alle meine Bibliotheken. Als Beispiel die library libdate_time.a D:\Prg\MCU\Avr\WinAvr\avr\my_libs\libdate_time.a D:\....\date_time\basic_utc.c D:\....\date_time\date_time.h D:\....\date_time\get_utc.c D:\....\date_time\Makefile D:\....\date_time\monats_tage.c D:\....\date_time\normalzeit.c D:\....\date_time\schaltjahr.c D:\....\date_time\set_time.c D:\....\date_time\sommerzeit.c D:\....\date_time\wochentag.c In D:\Prg\MCU\Avr\WinAvr\avr\my_libs befindet sich eine Batch-Datei, die alle Ordner durchgeht und dort (je nach Projekt) make MCU="atmega32" aufruft. Das jeweilige Makefile erstellt dann die Library und verschiebt sie in den my_libs Ordner. Wie geht Ihr vor? MfG
Besser wäre es meiner Meinung nach, wenn du nicht eine Lib erstellst, und diese dann jeweils für den gerade gebrauchten Controller neu kompilierst, sondern mit der Batch-Datei gleich alle Libs erstellst, mit dann natürlich passenden Namen. Also z.B. libmy-m8, libmy-m128, libmy-t13, etc. Und in den einzelnen Projekten dann natürlich die jeweils passende Lib angeben. So musst du nicht beim Projektwechsel neu kompilieren, sondern nur, wenn sich der Lib-Sourcecode ändert.
Wenn du in der Lib nur wenige Controller-Abhängigkeiten hast, kannst du auf Kosten von ein paar zusätzlichen Ressourcen die Lib auch unabhängig gestallten, indem du nur indirekt auf die Hardware zugreifst, z.B. über Pointer, die von der Applikation dann halt passend gesetzt werden müssen.
Das mit den prozessor-spezifischen Libs .... ja, das waere eine Ueberlegung wert. Denn schliesslich arbeite ich ja mit einer sehr beschraenkten Anzahl von MCU's. Das würde mich auch von der Sorge, einmal die Neu-Compilierung zu vergessen, befreien. Danke.
Genaugenommen mischt du ja zwei Probleme: Auch eine lib hindert dich nicht daran, bei jedem neuen Projekt darin rumzufummeln, und am Ende mit x verschiedenen lib-Versionen dazustehen. Das du das nicht tust oder musst, liegt halt an deiner Disziplin und an geeigneten aufgebauten libs. Das lässt sich aber genauso auf Sourcecode-Ebene umsetzen. Ausserdem gibt es nirgends auf der Welt ein Stück Software, von dem nicht doch irgendwann mal eine Version 1.1 erstellt wurde :-) Oliver
@Oliver Wieso? Wenn ich an meiner Lib herumfummle, gilt das Geaenderte für alle Projekte, die sich auf diese Lib beziehen. Wie soll es nach Deiner Meinung zu mehreren Libs kommen? Zumindest ist es mir in all den Jahren noch nicht gelungen, in eine Situation zu stolpern, wo ich mehere Libs-Versionen haette pflegen müssen.
>Wieso? Wenn ich an meiner Lib herumfummle, gilt das Geaenderte für alle >Projekte, die sich auf diese Lib beziehen. Schon fertiggestellten Projekte würde ich niemals ungetestet eine geänderte lib-Version unterschieben, und alles neu testen ist auch blöd. Nach jeder Änderung gibt es auch bei libs eine neue Version. Daher archivire ich selbst als reiner Hobby-Bastler nicht nur Sourcen, sondern auch den zugehörigen Compiler plus System-libs. Oliver
>Wieso? Wenn ich an meiner Lib herumfummle, gilt das Geaenderte für alle >Projekte, die sich auf diese Lib beziehen. Das solltest du nie nie nie machen. Falls du nämlich ein einem halben Jahr etwas änderst und dann gar nicht mehr weiss, wie die Funktion in all deinen 30 unterschiedlichen Projekten verwendet wird, kann es schnell passieren, dass irgendetwas altes nicht mehr funktioniert. Ich würde dann lieber mit Versionen arbeiten und bei Änderungen diese gegenüber den Vorversionen dokumentieren. So kannst du bei Verwendung eines alten Projektes sofort sehen, welchen Stand es hatte. Wenn es bisher Fehler frei funktioniert hat kannst du die "alte" Version einfach neu kompilieren. Falls doch Änderungen notwendig sind, kannst du anhand deiner Doku die Änderungen nachvollziehen und sehen, kannst abschätzen, was du neu Testen musst und ob die Änderung den Testaufwand wert ist. just my opinion. Steffen.
Mehmet Kendi wrote: > Wieso? Wenn ich an meiner Lib herumfummle, gilt das Geaenderte für alle > Projekte, die sich auf diese Lib beziehen. Na schönen dank auch, Du mußt wohl nie mehr alte Projekte warten oder erweitern? Wenn ich ein Projekt anfange, dann werden alle benötigten Bibliotheken eingefroren und mit im Projekt abgelegt. Wie sonst soll man denn später in der Lage sein, das Projekt wieder lauffähig zu compilieren? Man hat ja neuere Versionen der Bibliothek noch garnicht mit dem Projekt getestet. Und wenn sich die Bibliothek weiterentwickelt, kriegt das nächste Projekt die neue Bibliothek. Bei 30 Projekten kann es also auch 30 Versionen der Bibliothek geben. Wenn man es richtig professionell machen will, muß man sogar zu jedem Projekt die Compilerversion aufheben. Peter
Am besten Sourcecodeverwaltung verwenden. SVN oder so, auch wenn man es nur alleine nutzt. Dann kann man bei den alten Projekten mal die neue Bib probieren, wenns nicht geht switcht man wieder zur alten Version zurück...
Also es war nicht meine Absicht, hier eine Diskussion über Programmierstil zu entfachen. Ich wollte nur wissen, wie Ihr es mit den Libraries macht. Aber da nun mal der Beitrag in diese Richtung abdrifftet, will auch ich meinen Kommentar dazu geben. Ich gehe davon aus, dass es nichts gibt, was ich heute nicht besser machen würde als gestern. Und es gibt nichts, was ich morgen nicht besser machen würde als heute. Wieso soll ich also eine Funktion ruhen lassen, die ich heute besser programmieren würde? Ich bin seit nun bald 30 Jahren im Geschaeft, und ich hatte nur sehr wenige Projekte, die nach Uebergabe nicht mehr weiterlebten. Alle anderen Projekte entwickeln sich weiter oder starben eines natürlichen Todes (sprich: die Firma ging Konkurs, oder dergleichen); das aelteste ist jetzt bald 10 Jahre alt. Um auf die Frage von Peter zurückzukommen, ob ich nie alte Programme warten müsse: nein, weil keines meiner Projekte veraltet ist. Bei mir gibts nur "dead" oder "alive", aber kein "idle". Vielleicht auch gerade wegen dieser Art, wie ich meine Bibliotheken pflege.
Na, dann ist ja alles prima. Wobei, wenn du das schon seit 30 Jahren so machst, warum fragst du dann jetzt? Das System hat sich doch für dich bewährt. >Bei mir gibts nur "dead" oder "alive", aber kein "idle". >Vielleicht auch gerade wegen dieser Art, wie ich meine Bibliotheken >pflege. :-) Oliver
Aber genau das ist es ja, was die anderen kritisieren: Wenn du deine Lib für Projekt B änderst, diese aber vorher schon einmal in Projekt A verwendest, kann dir ja leicht passieren, dass du damit in Projekt A Fehler hinein bekommst, an die du gar nicht gedacht hast. Fehler die nur schwer zu finden sind. Daher macht es schon sinn mit jedem neuen Projekt auch eine Kopie der aktuellen Bibliotheken mit anzulegen. Änderst du dann was für dein neues Projekt an den Bibliotheken wirkt sich das erst einmal nicht auf die alten Projekte aus. Du kannst dir also 100% sicher sein, das sich das verhalten der alten Projekte nicht ändern wird, nur weil du ein neues Projekt beginnst. Wenn du dann beim Bearbeiten eines alten Projektes denkst, dass es günstiger wäre dazu eine aktuelle Bibliotheksfunktion zu benutzen kannst du ja immer noch händisch die aktuelle Bibliothek in das Projekt einpflegen und dann mit geeigneten Tests herausfinden ob sich dadurch Fehler einschleichen. Das mag erste einmal nach mehr arbeit aussehen aber das erspart dir dann vielleicht woanders peinliche oder gar schlimme Fehler und sicher auch ne Menge Zeit diese zu suchen. Natürlich bleibt hier das Problem das man ganz schnell mehrere aktuellere Versionen hat, also mehrere Bibliotheksmodufikationen die unabhängig voneinander entstanden sind. Das sehe ich bei mir immer als Problem und das ist es ja, was du mit deiner Zentralbibliothek verhindern wolltest.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.