mikrocontroller.net

Forum: Compiler & IDEs Mit Libraries Ordnung schaffen


Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.