[Erledigt] Unit Output Directory OS übergreifend

[charlytango]

Warum machst du daraus nicht ein Package? Packages sind die Antwort von Lazarus auf das Pfad-Chaos bei Delphi... Wenn jemand das verwenden will, muss er das entsprechende Package in die Anforderungen seines Projektes übernehmen, und schon kümmert sich die IDE darum, dass alles gefunden wird. Mache nur ein Laufzeit-Package, dann must du auch nichts installieren. Wenn du auf eine andere IDE umziehst (anderer Rechner, anderes BS, andere Version), dann musst du das Package nur einmal in der IDE öffnen, damit die IDE für die Zukunft davon weiß.

Also hat mich der Ehrgeiz gepackt und ich hab mal nachgelesen und mein erstes Laufzeit-Package erstellt. Dank Lazarus ging das besser als gedacht.

Wie ich das nun einsetze muss ich erst erforschen

Nur hat sich das "Framework" weiterentwickelt und kann unterschiedliche Rollen und Einsatzzwecke übernehmen. Macht es da nicht Sinn die Komplexitätsschwelle niedrig zu halten? Oder ist ein Package gerade das. Ich kann das irgendwie nicht beurteilen.

Andere Frage: Die Beispielapplikation soll wohl nicht mit ins Package nehme ich an?

[wp_xyz]

Weil ich bislang von Packages absolut null Ahnung habe

Einfach "Package" > "Neues Package". Dateinamen des Package angegeben - es kann im Dateisystem an beliebigem Ort liegen, ich würde es aber nicht in das Verzeichnis einer Lazarus-Installation legen (also etwa in c:\lazarus\components), denn wenn du dann irgendwann einmal die Installation löschst, ist dein Package weg). Dann "+ Hinzufügen" > "Dateien aus dem Dateisystem hinzufügen" und die gewünschten Units hinzufügen. Evtl musst du nach Abhängigkeiten eintragen; per default steht unter "Benötigte Packages" nur "FCL". Wahrscheinlich brauchst du auch die LCL: "+ Hinzufügen" > "Neue Anforderung" > in der List "LCL" suchen. Mit weiteren benötigten Packages wiederholen. Nun kannst du das Package kompilieren (Button "Kompilieren"). Wenn das gut durchläuft, bist du fertig und kannst dein Projekt öffnen und im Projektinspektor das neue Package unter "+ Hinzufügen" > "Neue Anforderung" eintragen. Nun kennt dein Projekt das Package und du kannst die dort verwendeten Units in "uses" eintragen".

Achtung: Da du vorher ohne Package gearbeitet hast, hast du wahrscheinlich das Verzeichnis mit den Package-Dateien schon im Suchpfad eingetragen. Das muss weg. Der Suchpfad ("andere Units" in den Projekt-Optionen") ist im Normalfall leer (es sei denn dein Projekt verwendet Unterverzeichnisse), alle benötigten Units werden über das Package-System gefunden.

[wp_xyz]

Andere Frage: Die Beispielapplikation soll wohl nicht mit ins Package nehme ich an?

Nein. Orientiere dich an der LCL oder anderen, dir bekannten Packages: Die Packages enthalten nur die benötigten Dateien. Beispiele sind immer Extra. Das Beispiel sollte natürlich dann das Package verwenden.

Berücksichtige immer auch die Abhängigkeiten, die du dir durch das Package ins Projekt holst. Ich versuche das anhand von FPSpreadsheet zu erläutern. Die gesamte Bibiliothek enthält verschiedene Arten von Abhängigkeiten:
- das Basis-Package enthält die Datenstruktur der Spreadsheets und die Lese/Schreibfunktionen verschiedener Dateiformate. Das benötigt nur elementare Funktionen aus FPC und (ich glaube) LazUtils.
- das visuelle Package (laz_fpspreadsheet_visual) enthält LCL-basierte Komponenten, die auf den Umgang mit Spreadsheets optimiert sind (TsWorksheetGrid).
- das visuelle Designzeit-Package (laz_fpspreadsheet_visual_design) enthält die Registrierung der Komponenten und Komponenten- und Property-Editoren für die IDE.
- und noch ein paar mehr.
Wäre alles in nur einem einzigen Package, würde ein einfaches Kommandozeilenprogramm, das eine Spreadsheet-Datei liest, die ganze LCL und auch die Property-Editoren, die nur die IDE benötigt, ins Projekt holen. Daher der Aufwand.

[charlytango]

Ich lese gerade zu Packages und hab das erste eben erfolgreich erstellt.

Mit deiner Erklärung bekomme ich das sicher hin.

Aber weiter und ums Eck gedacht:

Für jemand der eine Applikation baut und eine ausführbare Datei ausliefert ist das wohl kein Problem. Package von Github holen, irgendwohin kopieren, lpk-File einmal öffnen und dem Projekt hinzufügen - passt, ist vertretbarer Aufwand.

Wie sieht es mit jemand aus der ein Beispiel erstellt und vor allem was liefert er dann als Source mit?

Und derjenige der sich das Beispiel ansehen will muss wohl wiederum irgendwie das Package installieren und dem Beispielprogramm bekannt machen.

Meine Absicht war es auch Beispielprogramme öffnen zu können und Daten und Programm laufen einfach. Werden auch beim erneuten Öffnen und nachdem der User herumprobiert hat in einen definierten Datenzustand versetzt. Das Programm funktioniert einfach mit minimalstem Aufwand.

Meine Befürchtung ist, dass ich diesen Aspekt mit einem Package verschlimmbessere.

Deine Meinung dazu ?

[wp_xyz]

Meine Absicht war es auch Beispielprogramme öffnen zu können und Daten und Programm laufen einfach.

Irgend ein Beispielprogramm? Das wird nicht funktionieren ohne in irgendeiner Form den code des Beispielprogramms zu ändern. In deiner Version mit dem "Universal-Pfad" musst du den Suchpfad des Projekts erweitern, in meiner Version mit dem Package muss du im Beispielprojekt das neue Package hinzufügen.

Wie sieht es mit jemand aus der ein Beispiel erstellt und vor allem was liefert er dann als Source mit?

Er muss natürlich auch das Package mitliefern bzw. den Link zu github & Consorten, wo man es sich herunterladen kann. In deiner Version würdest du ja auch die Quelldateien mitliefern.

Schwierig wird's mit der Package-Lösung, wenn von verschiedenen Autoren der diversen Beispielprogramme verschiedene Versionen des Package verfügbar wären. Aber das wäre auch bei deiner Lösung ein Problem, da es den "Universal-Pfad" ja auch nur 1x gibt.

Ich muss aber sagen: So richtig habe ich dein Vorhaben nicht verstanden

[charlytango]

Der "universal" Pfad für das Unit Output Directory ist längst vom Tisch.
Ihr habt recht, dass das so nicht klappen kann.

Ausgangspunkt war dass ich mich immer irgendwie geärgert habe dass Beispielprogramme mit Datenbankzugriff oft an vielen Faktoren gescheitert sind. Mal war es auf einen Server abgestellt den ich nicht hatte und mal wurden eine Datenbank/Daten vorausgesetzt die ich nicht hatte oder eine Zugriffsbibliothek die ich nicht hatte.

Und weil ich nicht nur jammern wollte hab ich mich mal hingesetzt und geschaut was mit SQLDB möglich ist (ich selbst hab immer ZEOS verwendet, daher wars auch eine Lernkurve) denn Beispiele mit Drittkompionenten machen wenig Sinn.

Nun hat sich das ganze zu einem ausgewachsenen Datenbank-Zugriffsmodul für alle von Lazarus unterstützen SQL-Server entwickelt.

Und ein Beispielprogramm das jeder Entwickler für Beispiele mit ein paar Klicks so verwenden kann dass er auf einer beliebigen DB entwickelt und es jeder andere gegen einen beliebigen Server starten kann. Wenn gar nix eingestellt wird ist es SQLite. Daten werden automaitisch importiert.

Man kann das ganze mit einem bequemen Konfigurator auch so einstellen dass man es in Produktivumgebungen und auch mit Server- und DB-Umschaltung verwenden kann.

Nur als Hintergrundinfo