mikrocontroller.net

Forum: Compiler & IDEs Verwendung/Verwaltung von Bibliotheken mit GIT


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: TopperHarley (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich nutze seit einiger Zeit GIT zur Versionsverwaltung  meiner 
Softwareprojekte (privat und beruflich). Dabei stoße ich immer wieder 
auf ein Problem und hoffe es gibt dazu eine einfache Lösung. Angenommen 
ich habe mehrere Bibliotheken, welche sich jeweils in einem eigenen 
GIT-Repo befinden, wie z.B.:

UART-Repo
CAN-Repo
LCD-Repo
usw.

Diese Bibliotheken werden in mehreren Projekten verwendet und wachsen so 
mit der Zeit bzw. werden laufend verbessert.

Wie gehe ich hierbei am besten vor? Meine Wunschvorstellung wäre, dass 
ich die aktuellste Version der jeweiligen Bibliothek in mein aktuelles 
Projekt clonen, Änderungen vornehmen und diese anderen Projekten 
bereitstellen kann.

Habt ihr hierzu einige Tipps?

Danke für eure Hilfe!

Autor: Torsten C. (torsten_c) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
TopperHarley schrieb:
> ich nutze seit einiger Zeit GIT zur Versionsverwaltung  meiner
> Softwareprojekte (privat und beruflich).

Dann hast Du doch Erfahrung mit pull und push.
GIT ist es egal, ob das ein Softwareprojekt ist oder eine UART-Lib.

Was ist die Frage?

Autor: Ein Gast (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Du könntest z.B. die Bibliotheken als Submodul deinem Projekt 
hinzufügen.

https://git-scm.com/docs/git-submodule

Autor: M.K. B. (mkbit)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Was du suchst sind Submodule. Ich habe damit aber bisher keine 
praktische Erfahrung gemacht.

https://git-scm.com/book/de/v1/Git-Tools-Submodule

Der erste Satz klingt da fast wie dein Post.

Autor: TopperHarley (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten C. schrieb:
> Was ist die Frage?

Konkret geht es mir um die komfortable Nutzung, Wartung und 
Synchronisation  der Bibliotheken innerhalb der laufenden Projekte.

"Submodule" scheint das passende Stichwort zu sein. Vielen Dank für den 
Hinweis. Da werde ich mich mal einlesen.

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vorsicht, man man viel Quatsch damit bauen. Google mal “git submodules 
evil” 😄

Grundsätzlich ist git ein Software Revisionssystem. Die Nutzung als 
Dependency/Library Management Tool ist nicht die Hauptaufgabe. 
Spätestens bei verschiedenen Versionen deiner Libs wird es spaßig.

Idealerweise nimmt man einen Paketmanager, in .net zb Nuget, in Python 
pip. C is etwas komplizierter, es gibt aber zb von ARM sogenannte 
CMSIS-Packs, die in eclipse oder Keil uvision geladen werden können.

Das nur Vorab, wir nutzen auch submodules, aber man muss sich bewusst 
sein, was man tut ;)

Autor: S. R. (svenska)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Sinnvoll sind Submodule eigentlich nur, wenn man externe Abhängigkeiten 
im Quelltext im eigenen Projekt nutzen will. Das kommt dem, was du tun 
willst, zwar schon recht nahe, dann aber doch nicht.

Da du die Kontrolle über die Bibliotheken hast und sie 
höchstwahrscheinlich zusammen mit deinem Projekt entwickelst, handelst 
du dir mit Submodules wahrscheinlich mehr Ärger als Nutzen ein.

Du kannst dir stattdessen ja mal "repo" anschauen, dort besteht ein 
Projekt schlicht aus mehreren Git-Repositories, die du in einer 
XML-Datei angibst (inklusive Revision, Branch oder Tag). Android nutzt 
das, weil Submodules doof sind.

Autor: Slippin J. (gustavo_f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von Submodulen würde ich die Finger lassen (einfach mal googlen warum). 
Man kann ohnehin nur ein Submodul anlegen.

Ich denke auch das hier das "repo" von Google das richtige Tool ist.
Da gibt es eine Manifext-XML, in der alle GIT Repos eingetragen sind.
Man gibt dann das Kommando "repo sync" ein und alle Repos aktualisieren 
sich.

: Bearbeitet durch User
Autor: Michael Becker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Git submodule kann man schon verwenden. Man muss aber genau wissen, was 
man tut. Eine Alternative dazu wäre noch git Subtree. Subtree ist etwas 
einfacher zu bedienen als Submodule.

Autor: Le X. (lex_91)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
git submodule passt schon für die Aufgabenstellung.
Nimm dir aber Zeit für die Einarbeitung. Die Bedienung ist am Anfang 
etwas fummelig.

: Bearbeitet durch User
Autor: Frederic K. (warfley)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe die beste Erfahrung mit einem Workspace Script gemacht. Also 
einem Shell oder Python Script welches sich um alle dependencies 
kümmert. Grade für C(++) sehr hilfreich da man eventuell genau eine 
bestimmte Version einer Bibliothek benötigt, oder die version speziell 
gebaut werden muss (z.B. einen bestimmten Profiling Build, der einen 
ganzen Rattenschwanz an configure Argumenten braucht, oder eine 
Spezielle Version die du aus einem git tag oder branch auschecken 
kannst)

Somit habe ich dann ein Workspace Repository was das Checkout/Build 
Script enthält, welches alle dependencies auscheckt, korrekt baut und 
dann noch das eigene Projekt auscheckt und Konfiguriert für diese 
Dependencies. Außerdem können in das Repository dann noch weitere 
Scripts z.B. für spezielle Builds oder cleanup, etc. Das tatsächliche 
Projekt landet dann in einem anderen Repository und wird von dem Build 
script ausgecheckt.

Ansonsten sind wohl (wie bereits erwähnt) Submodules dein Freund

: Bearbeitet durch User
Autor: TopperHarley (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wollte mich noch einmal für eure Hilfe bedanken. Submodule sind 
genau das, was ich gesucht habe. Habe mich nun etwas eingearbeitet und 
nutze sie seit einigen Tagen. Bis jetzt ohne größere Probleme.

Liebe Grüße

TopperHarley

Autor: Christoph M. (mchris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo sollen denn die Probleme bei SubModulen liegen? Beispiel?

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph M. schrieb:
> Wo sollen denn die Probleme bei SubModulen liegen? Beispiel?

Es ist erstaunlich einfach, seine Sourcen in einen inkonsistenten 
Zustand zu bekommen, so dass man unbemerkt den aktuellen Quelltext mit 
einer alten Bibliothek baut oder umgekehrt. Erklärungen findest du bei 
Google.

Wenn man keine Fehler macht oder die Nutzung der Repositories 
größtenteils automatisiert, sind Submodule kein Problem.

Autor: Robert S. (robert_s68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls die Projekte nicht zu groß sind spricht auch nichts dagegen alles 
in einem git-repo zu lassen. Google-Stichwort "monorepo".

Autor: TopperHarley (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke es wird relativ fehleranfällig wenn man mehrere submodule in 
sein Projekt einbindet und Änderungen an den submodulen vornimmt. 
Wahrscheinlich kann es dann recht schnell passiert, dass man sich im 
falschen Unterordner befindet und/oder etwas versehentlich im falschen 
submodul oder Hauptprojekt commitet.

Autor: x^2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Submodules sind eine sinnvolle Sache (richtig angewandt zumindest) und 
wirken sich auf Strukturierung und Arbeit an den Projekten positiv aus.


- Submodules sind sinnvoll um Teile zu isolieren, die in mehreren 
Projekten eingesetzt werden sollen (oder können). Ohne submodules und 
einmal copy/paste in ein anderes Projekt driften die Kopien überraschend 
schnell auseinander. Das macht die Pflege dieser Teile (z.B. Bugfixing) 
sehr aufwändig.

- Submodules entkoppeln auch die Arbeit. Die Arbeit im Submodule streut 
nicht in die Historie des Hauptprojektes ein und bleibt somit klar 
isoliert. Ohne Submodules ist das Projekt meist ein waberndes Stück 
Etwas das von jedem, überall und dauernd geändert werden kann. Die Git 
Historie mit Branches und Merges wird schnell unübersichtlich. Big Ball 
of Mud. Aber manche Entwickler wälzen sich ja gerne wie die Schweine im 
Dreck :-)

- Submodules entkoppeln die Arbeit von Entwicklern. Drei Entwickler die 
in 3 verschiedenen Submodules arbeiten kommen sich garantiert nicht in 
die Quere. Im Gegensatz zu Branches des Hauptprojektes sind Merge 
Konflikte ausgeschlossen. Im Hauptprojekt können die Versionen der 
Submodules denkbar einfach aktualisiert werden (einfach ein Pull des 
Submodules), wenn deren Stand entsprechend solide ist. Bis dahin bleibt 
das Hauptprojekt und dessen Git Historie sauber.


Ich kann aus Erfahrung sagen, dass submodules helfen den Überblick zu 
behalten und viele Fehler zu vermeiden. Der Einsatz einer GUI zur 
Bedienung von Git kann allerdings hilfreich sein.

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.

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