Ich muss alte, in Delphi geschriebene Software pflegen. Der Quellbaum ist ein echtes Durcheinander. Ich versuche, zwei Dinge zu tun: eine saubere Verzeichnisstruktur zu schaffen und einen automatisierten Build-Prozess einzurichten.
Im Moment habe ich folgenden Verzeichnisbaum erstellt
%Vor% Das Verzeichnis \src enthält die Dateien *.pas und *.dfm und project.dpr . Verschiedene Ressourcen (Symbole, Bilder und Schriftarten) befinden sich im Verzeichnis \res . \env wird verwendet, um verschiedene Umgebungen für Debugging-Zwecke zu erstellen. IDE wurde eingerichtet, um project.exe in dieses Verzeichnis zu erstellen.
Build-Skripte werden im Ordner build gespeichert. Diese Skripte erzeugen Produktverteilung (mit und ohne Debug-Informationen in exe) in dist\release und dist\debug -Ordner mit Hilfe von dcc32.exe . build\output wird verwendet, um dcu-Dateien während des Build-Prozesses innerhalb der IDE oder im Build-Skript zu speichern.
Es gibt einen kleinen Fehler in meinem Ansatz. Ich kann nicht mit einem neuen Computer beginnen, den Code aus meinem Repo checken, mit dem Erstellen des Skripts beginnen und die bereitwillige Verwendung des Projekts erhalten. Ich muss zuerst die IDE öffnen, benötigte Komponenten installieren (z. B. RXLib und MemoEx ), Bibliothekspfade einrichten und so weiter. Erst danach kann ich meine Gebäudeskripte ausführen.
Es war bis letzte Woche kein großes Problem. Ich habe 3rd-Party-Komponente geändert, um einen Fehler zu beheben (diese Komponente wird nicht mehr gepflegt :-(), also muss ich Code dieser Komponente zur Struktur meines Projekts hinzufügen. An dieser Stelle, wenn ich auschecken werde Das Repo muss ich überprüfen, ob es Änderungen im Code von 3rd-Party-Bibliotheken gab. Wenn Code von Bibliotheken geändert wurde, muss ich Komponenten neu kompilieren und neu installieren.
Fragen
bpl und dcu platzieren, die während des Builds von Komponenten erzeugt werden? Sollte ich sie bei Project\build\output platzieren? Oder es ist besser, die Ausgabe an einen anderen Ort zu platzieren (überschreiben Sie nicht die Delphi-Einstellungen), aber ändern Sie den Bibliothekspfad in der Projektkonfiguration? Update: Bemerken Sie die Installation von der Befehlszeile Anfordern eines Teils der Frage.
Sie können nicht wirklich über die Befehlszeile installieren, aber es wäre einfach, etwas zu bauen das hat das gemacht. Sie können die Pakete mit DCC32.EXE kompilieren.
Die Installation von Komponenten wird durch Registrierungseinträge gesteuert. Der Speicherort in der Registrierung ist für jede Version von Delphi anders, aber er folgt demselben Grundmuster. Beispiele:
Delphi 2007 %Code% Delphi XE 'HKEY_CURRENT_USER \ Software \ Embarcadero \ BDS \ 8.0 \ Bekannte Pakete'
Wir aktualisieren dies mit FinalBuilder, nachdem wir alle Komponenten von Drittanbietern erstellt haben. Es macht es einfacher, jeden Entwickler synchron zu halten.
Wie bei der Verzeichnisstruktur denke ich über die Versionskontrolle im Voraus nach und mache folgendes:
Stammverzeichnis ...
%Vor%Dies ermöglicht mir, Zweige in einem einfachen Format zu erstellen.
%Vor%Von dort mache ich folgendes:
Ich benutze ein gemeinsames Verzeichnis für \ Bin und \ DCU, da ich eine Menge Paketentwicklung mache Viele davon müssen zur Entwurfszeit geladen werden. Dies verhindert, dass viele hinzugefügt werden müssen Verzeichnisse zum Systempfad, um Delphi glücklich zu machen.
%Vor%Dies kann verbessert werden, wenn es so sein muss:
%Vor%Für jedes Projekt mache ich das, obwohl ich oft mehr als ein Projekt in dasselbe setze Verzeichnis, wenn die meisten auf den gleichen Code beruhen.
%Vor%Endlich für Komponenten und Code, die für verschiedene Projekte gelten.
%Vor%Ich mache es so, also weiß ich alles, was meine Version X meiner Anwendung ausmacht, indem ich nur die Versionssteuerrevisionsnummer verwende.
Um das zu beenden, erstelle ich eine Umgebungsvariable für
C: \ DEV \ TRUNK \
Dann verwende ich die Umgebungsvariable im Pfad der Systembibliothek. So:
%Vor%Wenn ich dann die Zweige wechseln muss, kann ich die Umgebungsvariable Relaunch Delphi und alles, was diese Version der Codebasis verwendet, ändern.
Sie müssen das Paket nur mit dem Delphi-Kommandozeilen-Compiler kompilieren. Wenn sich der Delphi-Bin-Pfad in Ihrem PATH befindet, müssen Sie den Installationspfad nicht fest codieren. Wenn Ihr Build-System aus der Registrierung lesen kann, erhalten Sie den Pfad z. HKEY_LOCAL_MACHINE\SOFTWARE\CodeGear\BDS.0\RootDir (in diesem Fall Delphi 2009).
Ich würde einen weiteren Zweig components mit Subbranches für jedes Paket hinzufügen. Vermische sie nicht mit deinen Projekten.
Nach meiner Erfahrung ist es am besten, sie im Delphi-Ziel zu belassen (wo es von der Delphi-Version abhängt).
1: Ja und nein, Sie können eigene Komponenten entwerfen, die über die Befehlszeile installiert werden sollen (wobei "von der Befehlszeile" bedeutet, dass sie programmatisch installiert werden) könnte das Werkzeug schreiben müssen). Komponenten von Drittanbietern werden in der Regel mit einem Installationsprogramm geliefert, das die Komponenten selbst installiert und registriert. Theoretisch können Sie alles, was der Installer tut, automatisieren und die Komponente für den eigenen Gebrauch neu verpacken, aber dabei stoßen Sie möglicherweise auf rechtliche Barrieren.
2: Komponenten von Drittanbietern sind nicht an ein Projekt gebunden. Das Speichern dieser Dateien im Projektverzeichnis ist keine gute Idee. Was passiert, wenn Sie dieselben Komponenten in einem anderen Projekt wiederverwenden? Kopieren Sie alle Quelldateien in das neue Projekt? Für meine eigene Arbeit habe ich alle Komponenten von Drittanbietern in einem Ordner getrennt von jedem Projektverzeichnis installiert, und ich behalte diesen Ordner unter Versionskontrolle.
3: Die Verwendung eines separaten Ausgabeverzeichnisses für jedes Projekt ist eine gute Idee, es macht die Verwendung der bedingten Kompilierung viel einfacher. Ich würde separate Ausgabeverzeichnisse für Debug und Release vorschlagen. Über Drittanbieter-BPLs sind sie auch nicht Teil des Projekts, weil kein einzelnes Projekt sie "besitzt".
Tags und Links delphi build-automation components project-structuring