Strategie und Struktur für Packages/Komponenten

[charlytango]

Hi,

eine Frage nach eurer Erfahrung.
Nachdem ich mein erstes Package zusammengebaut habe kommt auch die Idee für weitere (zb Interne).

Wie strukturiert ihr das Verzeichnis eines Package? Gibt es da eine Best Practise?

Manche haben den Source gleich auf dem ersten verzeichnislevel, andere in einem eigenen Source-Verzeichnis. Dann kommen noch Demos dazu, evtl Ressourcen und zumindestens ein Verzeichnis in dem man eine Applikation für die Basisentwicklung hat. Wie sind da eure Erfahrungen dazu.

Das Verzeichnis für die Entwicklung mit ins Package oder nicht?

Wie strukturiert ihr das wenn man möglichst wenig Aufwand mit dem zusammenpacken für OPM, GIT etc haben will?

So wie es aussieht macht das jeder anders -- meine Frage geht in Richtung Erfahrungen und Strategien die gut laufen.

[af0815]

Schau mal ins Verzeichnis von Components von Lazarus (oder in OPM), da hast ein paar Beispiele.

[charlytango]

hab ich als erstes gemacht -- es gibt eine klare Linie zu erkennen -- Jeder macht es wie er mag

[wp_xyz]

Bei kleinen Packages kann man meinetwegen alles im Package-Rootverzeichnis belassen. Sobald aber mehr als ein paar Dateien beteiligt sind, würde ich das alles sauber strukturieren: source, include, resource, images, languages, examples, help/doc, tests (oder alles was mit dem Kompilieren des Packages zusammenhängt nach source: source, source/include, source/resource, alle Zusatzdateien dagegen in Ordner neben source). In source Unterverzeichnisse für runtime und designtime. Die Trennung in Runtime- und Designtime-Packages ist sinnvoll, um zu verhindern, dass der nur von der IDE-verwendete Code (darunter auch die Paletten-Icons) im User-Projekt landet. Aber: Das Designtime ruft das Runtime-Package nur in seinen Anforderungen auf, keinesfalls darf es den Pfad zu den Quellen des Runtime-Packages kennen, um Compilier-Probleme zu verhindern. Auch müssen die Ausgabeverzeichnisse von Runtime und Designtime-Package getrennt sein. Die Package-Dateien (*.lpk) packe ich am liebsten ins Rootverzeichnis, so dass sie beim Öffnen des Package sofort gefundenen werden, oder in einen Packages-Unterordner (vor allem wenn man auch Delphi mit eigenen Packages unterstützt).

Strenggenommen muss ein Package nur die für das Übersetzen benötigten Dateien enthalten. Aber man tut dem User mit so einer Minimalausstattung keinen Gefallen. Es sollte zumindest ein Beispielprojekt beigefügt sein, an dem an sieht, was das Package macht und wie man es anwendet.

[Mathias]

Wie strukturiert ihr das Verzeichnis eines Package? Gibt es da eine Best Practise?

Für SDL3 habe ich es so gemacht. Der Package Ordner sauber halten, die Beispiele ausserhalb des Package Ordners.
Dann habe ich noch einen sandbox Ordner für Tests, der kann der Anwender getrost ignorieren.
Wen ich noch Hilfstools für die Package habe, die kommen auch in eine Extra-Ordner.

https://github.com/sechshelme/Lazarus-S ... d-Examples

Da habe ich auch noch ein Beispiel einer grösseren Sammlung von Packages.
Dies ist (noch) nicht so toll. Das muss ich bei Gelegenheit noch ein wenig umordnen.

https://github.com/sechshelme/Lazarus-G ... d_Examples

So nebenbei wen ich für die LCL eine Package machen würde, dann würde ich sowieso voraussetzen, das man die Komponenten dynamisch lädt. Ich bin da nicht so Fan die Komponenten direkt in die IDE rein zu kompilieren.

[Warf]

Ich strukturiere meine Packages sehr ähnlich zu meinen Projekten:

Code: Alles auswählen

<root>/package.lpk
<root>/Readme.md
<root>/src/... # Source files
<root>/examples/... # Beispiele
<root>/doc/... # Markdown dokumentation falls notwendig
<root>/tests/... # Unittests falls notwendig

Wobei ich auch namespaces Nutze um interne und externe Funktionalitäten zu trennen. Ein gutes Beispiel hier ist meine Iterator Bibliothek die Unit "Iterators" ist die die die Nutzer einbinden müssen in ihr Projekt, welche intern dann die "Iterator.XYZ" Units benutzt. Somit habe ich zwar viele verschiedene Units um meinen Code schön logisch zu Struzkturieren, wer die Bibliothek aber benutzen will muss nur eine einzige Unit zur uses-Klausel hinzufügen.

Und bei den Unittests, wenn ich überhaupt welche habe, bin ich sehr low effort einfach ein simples Program mit exit codes baue, und mir grade schnell einen Testrunner in Python zusammen hacke. Wirkliche testing Frameworks benutze ich eigentlich nie.
Also für die Arbitrary Precision Number Unit die ich grade bastel sieht der test wirklich einfach so aus:

Code: Alles auswählen

{ %INCLUDE=utils }

Program TestCompare;

uses
  Numbers;

begin
  if -TInteger(0) < TInteger(0) then
    Halt(1);
  if -TInteger(3) < -TInteger(5) then
    Halt(2);
  ...
  WriteLn('Ok');
end.

[hum4n0id3]

Und bei den Unittests, wenn ich überhaupt welche habe, bin ich sehr low effort einfach ein simples Program mit exit codes baue, und mir grade schnell einen Testrunner in Python zusammen hacke. Wirkliche testing Frameworks benutze ich eigentlich nie.

Warum nicht? Ich aktualisiere gerade ein Bund an fremden, also nicht von mir, Open Source Bibliotheken und bin sehr froh das diese Tests haben. So gehe ich sicher das Bibliotheken auch danach laufen. Ohne Tests fasse ich das Zeug sonst nicht an, da zu unsicher.

Auch sonst wenn die Software noch einen kleinen Umfang hat, erspart man sich viele Probleme, wenn man Tests hat und sieht, ob noch alles zusammen passt. Also ich mag Tests

[Warf]

Ich mag auch tests, wenn ich was mache was sich gut testen lässt fang ich meistens damit an das ich die Tests schreibe was funktionieren soll und danach erst meinen Code so baue das das was ich vorhabe auch Funktioniert.

Das Problem ist eher das in vielen Situationen tests zu schreiben sehr kompliziert sein kann. Meine letzten 3 großen Projekte die live gegangen sind, waren meine Websockets Bibliothek, meine ANSI Escape Sequence Terminal Bibliothek und meine Co-routine implementation. Die automatisiert zu testen ist echt nicht so angenehm, bei der Websocket Bibliothek hatte ich am anfang den Clienten gegen den Server getestet, was sich gut als unit test machen lässt. Problem wenn ichs benutzen wollte ging sehr viel kaputt, weil ich im Grunde meine eigenen Bugs und Misverständnisse getestet habe. Daher hab ich da statt tests einfach mehrere Examples die die ganze Funktionalität abdecken sollen gebaut.
Bei der Terminal Bibliothek ist das sehr ähnlich, hier ist die Hauptfehlerquelle inkompatibilitäten mit verschiedenen Terminal Emulatoren, daher hab ich da auch vor allem sehr viele Beispielprogramme drin.

Unittests machen erst Sinn wenn man wirklich komplexe Logik Baut. Bei meinem Compiler Compiler an dem ich seit letztem Jahr sitze hab ich vor allem extrem viele für die DFA Konstruktion und parser, weil sich die einfach testen lässt. Für ein anderes Projekt brauche ich einen Arbitray but Fixed Sized Integer typen, den kann man auch gut mit unittests testen.

Der Grund warum ich kein Testing Framework verwende ist aber super simpel, ich brauchs nicht wirklich, ich hab einfach meinen Python Testrunner der durch alle tests in einem Ordner durchiteriert, über Kommentare im code configuriert werden kann, und einfach nur testet:
1. Kompiliert es (und solle es das)
2. Wenn ich den Test ausführe, returned der 0 (success) oder einen Fehlercode, und am ende zeigt der mir die tests an die Fehlschlagen.
Keine packeges oder andere dependencies, nur ein 200 zeilen Python script und standard .pas dateien, mehr ist für meine Tests nicht notwendig

Bei meinem letzten C Projekt einem Emulator, hab ich die einfach direkt mit in den Makefile gelegt, dann wars sogar teil des regulären buildsystems