Gemeinsame Units für Projekte?

[alfware17]

Ich habe noch eine Frage. Verschiedene Lazarus-Projekte könnten sich bei mir gemeinsame Units teilen,
was vieles vereinfachen würde. Bisher kopiere ich die zwischen den Verzeichnissen bzw synchronisiere mit Totalcommander.
Gibt es einen Weg, die gemeinsamen Units irgendwo zentral zu verwalten?
Natürlich weiß ich daß es ein Problem gibt, wenn die Projekte dann unterschiedliche Versionen haben und auch
unterschiedliche Versionen der Units brauchen und ich mir dann nur mehr Arbeit mache als Nutzen habe,
Aber so generell? Wenn die Units relativ unverändert bleiben und die Projekte die gerade gleich benutzen sollen
(es sind so 3-5 Units). Abgesehen von Standard-Units, die ich aber noch mal woanders wieder habe, damit sie
von verschiedenen zB FPC und Lazarus gefunden werden können

[corpsman]

Also ich habe ettliche solcher Units die ich auf fast alle meine selbstgeschriebenen Programme verteille.
Da ich grundsätzlich keine Binaries auf meiner Platte habe werden alle Programme die ich nutze beim Starten durch meine Scripte automatisch gebaut und dann gestartet (zum Glück ist der FPC-Compiler derart schnell dass das geht).
Damit haben alle meine Projekte immer die aktuellste version aller units, und ich merke auch sehr schnell wenn ein Program nicht mehr kompatibel sein sollte. (BTW viele dieser Units habe ich hier auch öffentlich gemacht). Dort kannst du auch sehen wie ich das bei mir organisiere. So als einzelkämpfer ist das ok und gut.

Auf Arbeit organisieren wir solche Dateien in eigenen Repositories und binden diese als Submodule in die Hauptprojekte ein, dass hat den Vorteil dass man dann selbst den Aktualisierungszeitpunkt bestimmen kann, weil sich GIT den SuperProjekt Pointer merkt und den auch nicht automatisch hoch zieht.

So nun hast auf jeden Fall mal 2 Möglichkeiten wie man das machen kann

[Sieben]

Pack die gemeinsam genutzten Units in Packages, die dann von allen deinen Projekten als Abhängigkeiten genutzt werden. Genau dafür gibt es dieses Konzept.

[Mathias]

Pack die gemeinsam genutzten Units in Packages, die dann von allen deinen Projekten als Abhängigkeiten genutzt werden. Genau dafür gibt es dieses Konzept.

Dies mache ich auch immer so. Dies hat den Vorteil, das man in den Pojekten nicht immer den Unit-Pfade anpassen muss.

[MmVisual]

Ich glaube du solltest eine Quellcode Verwaltung einführen.
Beispiele: SVN, GIT, Mercurial ...

Damit kann man nicht nur den Quellcode sichern und bequem mit alten Ständen vergleichen, sondern bietet noch den Vorteil von Subrepositories.

Man legt seine Bibliotheken in ein seperates Repository ab und kann in seinem Projekt dies als Subrepository einbinden.
Diesem Subrepository sagt man dann dass es in Version XXX zum Projekt gehört. Möchte man im Projekt eine neuere Version haben so kann man das Subrepository updaten.

Vorteil: Alte Projekte funktionieren dann immer noch. Wenn man alte Projekte auf die neue Bibliothek updates, dann kann man das jederzeit machen.
Damit muss man sich erst einmal keine Gedanken darum machen dass bei einer Änderung die vielen anderen abhängigen Projekte dann sofort auch nachgezogen werden müssen, sondern kann das dann machen wenn man ein anderes Projekt ebenfalls ändert.

[wp_xyz]

Pack die gemeinsam genutzten Units in Packages, die dann von allen deinen Projekten als Abhängigkeiten genutzt werden. Genau dafür gibt es dieses Konzept.

Dies mache ich auch immer so. Dies hat den Vorteil, das man in den Pojekten nicht immer den Unit-Pfade anpassen muss.

Ja, so ist es gedacht. Allerdings habe ich viele Lazarus-Installationen, und weil Zusatzpackages erst der IDE bekannt gemacht oder installiert werden müssen, ist es immer relativ aufwendig ein Projekt in einer anderen Installation zum Laufen zu kriegen. Daher gehe ich in letzter Zeit immer mehr dazu über, den Quellcode der Zusatzpakete in ein Unterverzeichnis des Projekts zu kopieren und den Pfad darauf unter "Other unit files" im Projekt einzutragen. Zusatz-Komponenten, soweit erforderlich, erzeuge ich im Quelltext, muss also nichts installieren. Dieses Vorgehen hat natürlich nur dann Sinn, wenn die Zusatzpackages ausgereift sind und nicht alle paar Wochen aktualisiert werden müssen.

[CCRDudeLaz]

Ja, so ist es gedacht. Allerdings habe ich viele Lazarus-Installationen, und weil Zusatzpackages erst der IDE bekannt gemacht oder installiert werden müssen, ist es immer relativ aufwendig ein Projekt in einer anderen Installation zum Laufen zu kriegen. Daher gehe ich in letzter Zeit immer mehr dazu über, den Quellcode der Zusatzpakete in ein Unterverzeichnis des Projekts zu kopieren und den Pfad darauf unter "Other unit files" im Projekt einzutragen. Zusatz-Komponenten, soweit erforderlich, erzeuge ich im Quelltext, muss also nichts installieren. Dieses Vorgehen hat natürlich nur dann Sinn, wenn die Zusatzpackages ausgereift sind und nicht alle paar Wochen aktualisiert werden müssen.

Tipp: wenn man ein VCS verwendet, kann man oft auch Untermodule verwenden (git submodule add ...). Dann muss man nichts rumkopieren, sondern hat für diese Unterpakete den gleichen Vorteil der Versionsverwaltung., und kann diese mit einem Befehl aktualisieren oder auf einen alten bekannten Stand zurücksetzen, ohne ewig hin und her kopieren zu müssen.

[schoschy]

Ich würde hierfür Symlinks/Verknüpfungen empfehlen.
Klar kann man es auch über packages, git oder sonstiges realisieren, das macht es mMn aber nur unübersichtlich.
git im entwicklungsteil der Units.
Die Unit selbst verknüpft in die Projekte.

Man halt also pro Arbeitsumgebung einmal das Git, welches man aktuell halten kann, wodurch alle Projekte direkt eine Änderung referenziert haben.
Wenn man doch mal eine andere Version der Units benötigt, kann man die auch direkt kopieren und anpassen.

Ich selbst halte solche Sammlungen über Syncthing direkt zwischen allen Arbeitsumgebungen aus meinem Git aktuell, das ist aber wie so vieles eine Geschmacks- und Aufwandsfrage.

[CCRDudeLaz]

Stell Dir mal vor, Du führst einen Bug in einer Deiner allgemeinen Units ein. Über Symlink / Verknüpfung schiebst Du den automatisch in alle Projekte. Jede Änderung an einer allgemeinen Unit triggert damit automatisch neue QS für alle Projekte. Dann musst Du erstmal rausfinden, welche Projekte da Symlinks drauf haben, und die alle testen. Was für ein Riesen-Aufwand. Und das alles, während eines der Projekte vielleicht gerade auf einen Release wartet und eigentlich schon fertig getestet ist, Du willst nur noch einen kleinen String ändern und neu kompilieren, führst damit aber neuen Code ein...

Mit Git-Submodulen kannst Du entscheiden, wann Du Neuerungen in allgemeinen Units in die jeweiligen Projekte übernimmst. Das ist sowas von entspannter (für mich)

[alfware17]

Pack die gemeinsam genutzten Units in Packages, die dann von allen deinen Projekten als Abhängigkeiten genutzt werden. Genau dafür gibt es dieses Konzept.

Dies mache ich auch immer so. Dies hat den Vorteil, das man in den Pojekten nicht immer den Unit-Pfade anpassen muss.

Wo finde ich denn Packages bzw wie mache ich das? Sorry wenn ich so einfache Sachen nicht weiß... Bisher habe ich immer mein ganzes Projekt in einem Ordner,
bei einer neuen Programmversion mache ich eben einen neuen Ordner. Und verschiedene Projekte haben eben verschiedene Ordner. Oder sollte ich mal mehrere Projekte in einen Ordner machen, damit die Unit gemeinsam gefunden werden? Das würde ich nicht so gut finden,,,

[schoschy]

Stell Dir mal vor, Du führst einen Bug in einer Deiner allgemeinen Units ein. Über Symlink / Verknüpfung schiebst Du den automatisch in alle Projekte. Jede Änderung an einer allgemeinen Unit triggert damit automatisch neue QS für alle Projekte. Dann musst Du erstmal rausfinden, welche Projekte da Symlinks drauf haben, und die alle testen. Was für ein Riesen-Aufwand. Und das alles, während eines der Projekte vielleicht gerade auf einen Release wartet und eigentlich schon fertig getestet ist, Du willst nur noch einen kleinen String ändern und neu kompilieren, führst damit aber neuen Code ein...

Mit Git-Submodulen kannst Du entscheiden, wann Du Neuerungen in allgemeinen Units in die jeweiligen Projekte übernimmst. Das ist sowas von entspannter (für mich)

Muss ich mir nicht vorstellen.
Jeder muss selbst für sich definieren, was für Units allgemein gehalten werden - bei mir sind es ausschließlich Socketprotokolle, lazyman-functions und Berechnungen, welche nach Fertigstellung nicht mehr angepasst werden müssen. Wenn ein Protokoll eine neue Version erhält, erstelle ich auch eine neue Unit dazu.


Ich glaube auch, dass es alfware17 primär um das Sammeln von Ideen ging. Welche es wird, obliegt auch nicht uns, die erste Richtung ist erkennbar.

Oder sollte ich mal mehrere Projekte in einen Ordner machen, damit die Unit gemeinsam gefunden werden? Das würde ich nicht so gut finden,,,

Davon würde ich auch abraten.

[CCRDudeLaz]

..., welche nach Fertigstellung nicht mehr angepasst werden müssen.

Bei so viel Können, die aus "mein Code ist unfehlbar, der muss nie wieder angepasst werden" strahlt, ziehe ich meinen Hut und gehen mir die Argumente aus

Vor allem aber bewundere ich Deine weise Voraussicht, die dieselbe Perfektion bei jedem, der Deine Empfehlung liest, auch schon als gegeben wahrnimmt!

[CCRDudeLaz]

Wo finde ich denn Packages bzw wie mache ich das?

Du erstellst ein Verzeichnis für die Units, die Du in einem Package sammeln willst. Dann wählst Du in Pascal File -> New... -> Package -> Package.

Darauf öffnet sich ein Fenster ähnlich dem Projektmanager, in dem du die Units hinzufügst, das Package natürlich im selber Verzeichnis speicherst (ich verwende gerne eine Unterstruktur im Sinne von Ordnern source\, lib\, bin\, und packe nu das Package in das eigentliche Verzeichnis).

Wenn dann ein Projekt eine der Units verwenden soll, gehst Du dort im Projektmanager auf Add... -> New Requirement -> Name des obigen Packages.

Dann musst Du keine Pfade mehr anpassen.

Der Debugger springt dann aber ggfls. nicht mehr in Units in dem Package. D.h. das ist auch ein guter Punkt, ordentliche code tests zu schreiben (File -> New... -> Project -> FPCUnit Test Application).

[wp_xyz]

Wo finde ich denn Packages bzw wie mache ich das?

Erzeuge einen Ordner für gemeinsame Units, z.B (ich bin auf Windows) c:\Progs\allgemein. In den kopierst du alle allgemein zu verwendenden Units. Dann gehst du auf "Package" > "Neues Package", denke dir einen schönen Namen für das Package aus, z.B. "EigeneUnits" und speichere es in dem "allgemein"-Order. Damit hast du ein leeres Package erzeugt. Gleichzeitig hat sich der Package-Editor geöffnet, der ähnlich aussieht wie der Projekt-Inspektor. "Hinzufügen" oder Rechtsklick auf "Dateien" > "Dateien aus dem Dateisystem hinzufügen", dann alle Units auswählen, die ins Package sollen. "Speichern" - fertig.

Du kannst noch etwas Feinschliff anlegen: Im Package-Editor "Einstellungen" > "Package-Einstellungen" "Beschreibung": Da kannst du dokumentieren, wofür das Package gut ist; unten kannst du auch eine Versionsnummer angeben. Und wenn du das Package veröffentlichen willst, kannst du auch Lizenz-Bedingungen eintragen.

Unter "Package-Einstellungen" > "IDE-Integration" kannst du festlegen, wie das Package dem System bekannt gemacht wird: Wenn du nur Utility-Funktionen in den Package-Units hast, die nur zur Laufzeit aufgerufen werden, ist die Einstellung "Laufzeit" oder "Nur für Laufzeit" richtig (weiß gar nicht, was der Unterschied zwischen den beiden ist); es geht auch "Entwicklungs- und Laufzeit"; in diesem Fall muss in einer neuen Lazarus-Installation das Package nur einmal geöffnet werden, und die IDE weiß bescheid, wo sich das Package und seine Units befindet. Enthalten deine Units aber z.B. Komponenten, die in der Komponentenpalette erscheinen sollen, oder IDE-Erweiterungen, dann musst du "Entwicklungzeit" und/oder "Entwicklungs- und Laufzeit" einstellen. Bei den Units, die Registrierungscode enthalten ("procedure Register"), muss auch das Häkchen bei "Registriere Unit" gesetzt sein. In diese Variante muss bei einer neuen Installation zunächst das package geöffnet und dann dort auf "Verwenden" und "Installieren" geklickt werden, anschließend wird die IDE neu kompiliert.

Um das neue Package nun in deinem Projekt zu verwenden, öffnest du den Projekt-Inspektor. In der Baumansicht klickst du unten mit der rechten Maustaste auf den Zweig "Benötigte Packages"; nach "Hinzufügen" kommt der Dialog "Neue Anforderungen", in dem du dein neues Package "Eigene Units" in der Package-Liste auswählst. Nach "OK" kennt dein Projekt das neue Package, und du kannst die enthaltenen Units per "uses" verwenden.

Dasselbe machst du mit jedem Package, in dem das Package verwendet werden soll.

Achtung: Du musst anschließend natürlich die Package-Units, die du von der packagelosen Version deines Projekts noch im Projekt-Ordner hast, löschen. Es hat mich einige graue Haare gekostet, herauszufinden, warum Änderungen an einer Package-Unit nicht ins Projekt übernommen wurden (nämlich weil noch eine alte Unit-Version im Projekt-Ordner herumgeisterte).

Wenn du mit dem Debugger in die Package-Units gelangen willst, öffne die Projekt-Optionen, "Hinzufügungen und Beeinflussungen" > "Hinzufügen" > "Benutzerdefinierte Option" und trage in der Zeile "Custom" den Ausdruck "-gw3" ein (ohne Anführungsstriche). Damit werden verwendeten Units mit Dwarf3-Debuginformation neu kompilieren (außer FPC-Units).

[alfware17]

Ich danke euch für die gute und ausführliche Anleitung! Das hilft mir erstmal enorm weiter, ein bißchen System und Ordnung reinzubringen...