Pbuild: Unterschied zwischen den Versionen

Aus Wiki des Deutschsprachige Xbaseentwickler e. V.
Zur Navigation springen Zur Suche springen
K
K
Zeile 1: Zeile 1:
=PBuild ist der ProjectBuilder von Alaska Software.=
==PBuild ist der ProjectBuilder von Alaska Software.==


PBuild steht in der Tradition eines make unter Unix. Unter Xbase++ dient PBuild sowohl der Erstellung einer Projekt-Definitions-Datei, als auch dem Erstellen der Objekte (Plural, wohlgemerkt).
PBuild steht in der Tradition eines make unter Unix. Unter Xbase++ dient PBuild sowohl der Erstellung einer Projekt-Definitions-Datei, als auch dem Erstellen der Objekte (Plural, wohlgemerkt).

Version vom 13. Mai 2013, 13:55 Uhr

PBuild ist der ProjectBuilder von Alaska Software.

PBuild steht in der Tradition eines make unter Unix. Unter Xbase++ dient PBuild sowohl der Erstellung einer Projekt-Definitions-Datei, als auch dem Erstellen der Objekte (Plural, wohlgemerkt).


Wie erstellt man eine Projekt-Definitions-Datei (Erweiterung .xpj)?

Es geht sicherlich manuell anhand vorhandener Beispiele, es geht aber auch automatisch. Für den automatischen Betrieb benötigen wir eine Liste der Module, die das Projekt ausmachen. Vorzugsweise als Textdatei, mit einem Dateinamen je Zeile, getrennt durch CRLF.

Erzeugt wird die Projekt-Definitions-Datei dann mit

pbuild @project.txt

wobei PBuild in diesem Fall einige "Vermutungen" anstellt über die Art des Programms:


Aufbau einer Projekt-Datei

[PROJECT]
   COMPILE       = xpp
   COMPILE_FLAGS = /q
   DEBUG         = yes
   GUI           = no
   LINKER        = alink
   LINK_FLAGS    = 
   RC_COMPILE    = arc
   RC_FLAGS      = /v
   PBUILD        = @project.txt
   MAKE          = 
   PROJECT.XPJ

Standard-Schlüsselwörter der automatisch erzeugen Projekt-Datei

COMPILE = xpp

legt fest, dass als Compiler xpp.exe aufgerufen werden soll. Ein abweichender Eintrag macht keinen Sinn.


COMPILE_FLAGS = /q

legt fest, dass an xpp.exe lediglich den Schalter /q (für quiet) übergeben wird


DEBUG = yes

aktiviert die Debugging-Unterstützung


GUI = no

legt fest, dass es sich um ein Text-Modus Programm handeln soll (!)


LINKER = alink

definiert ALink von Alaska Software als Linker für das Erstellen des abschliessenden Programms (oder der DLLs)


LINK_FLAGS =

Im Standard erhält ALink keine weiteren Schalter.


RC_COMPILE = arc

bestimmt arc.exe als Compiler für Resourcen, die in das Programm/die DLL eingebunden werden sollen. Auch dieses Programm wird von Alaska bereitgestellt.


RC_FLAGS = /v

übergibt /v als Schalter an arc.exe (wobei /v für "verbose mode" steht).


PBUILD = @project.txt

hierzu gibt es keine Dokumentation, dem Anschein nach wird hier nur festgehalten, aus welcher Datei die aktuelle Projekt-Datei erzeugt wurde


MAKE = 

hierzu gibt es leider keine Dokumentation.


Im Anschluss an diese vorgegebenen Schlüsselwörter kommen benutzerdefinierte, wie das standardmässige generierte

PROJECT.XPJ

mit dem ein Eintrag definiert wird, der abzuarbeiten ist


weitere Schlüsselwörter

Es gibt noch weitere Schlüsselwörter, die für Spezialfälle benötigt werden:



INCLUDE=

Dieses Schlüsselwort definierte weitere Pfade, in denen nach .CH-Dateien gesucht werden soll


LIB=

Dieses Schlüsselwort definierte weitere Pfade, in denen nach .LIB-Dateien gesucht werden soll


OBJ_DIR=

Standardmässig werden Objekte im Verzeichnis abgelegt, in dem PBuild ausgeführt wird. Über OBJ_DIR kann ein (!) Verzeichnis spezifiziert werden, in dem .OBJ-Dateien abgelegt werden. Der Linker greift ebenfalls auf dieses Verzeichnis zu, wenn es spezifiziert ist.


OBJ_FORMAT=COFF/OMF

POST_BUILD=

POST_CLEAN=

PRE_BUILD=

PRE_CLEAN=


Benutzer-definierte Bereiche

Mit den bisherigen Angaben wird das Umfeld der Projekterstellung festgelegt, nicht jedoch, WAS getan werden soll.

Der letzte Eintrag im ersten Abschnitt weisst PBuild an, nach einem Abschnitt mit dem gleichen Namen zu suchen. In dem obigen Beispiel erwartet PBuild einen Abschnitt [PROJECT.XPJ]

Unter diesem Eintrag werden die Ziel-Objekte aufgelistet:

[PROJECT.XPJ]
   Meine.DLL
   Meine.EXE

Während die beiden Einträge PROJECT.XPJ / [PROJECT.XPJ] beliebig benannt werden können (auch HUGO / [HUGO] würde funktionieren), sind die Angaben hier die Namen, unter denen die erzeugten Objekte im Zielverzeichnis erzeugt werden.

Jeder Eintrag in diesem Abschnitt muss wiederum als neuer Abschnitt definiert werden:

[Meine.DLL]
   MeineDll.prg
   MeineIrgendwas.prg

[Meine.exe]
   meineexe.prg
   nocheineandere.prg

Die Namen müssen, was Gross- und Kleinschreibung angeht, nicht identisch sein, d.h. MEINE.EXE, meine.exe und Meine.Exe werden als übereinstimmend angesehen.



Generieren der Abhängigkeiten

Wer mit make unter Unix, Linux oder auch Windows gearbeitet hat, weiss, dass make "tiefer" hineinschaut. Nehmen wir an, in meineexe.prg wird meine.ch verwendet. Wenn meine.ch geändert wird, muss meineexe.prg neu compiliert werden. Diese Abhängigkeit ist aus dem o.a. Beispiel nicht abzuleiten.

Wenn PBuild /g aufgerufen wird, liest PBuild die betroffenen Programme und analysiert die Abhängigkeiten, dazu gehören eben auch eingebundene Include-Dateien, oder die Tatsache, dass PBuild annimmt, dass MEINE.EXE von MEINE.DLL abhängig ist.

Um die benutzerdefinierten Einträge von den automatisch generierten zu unterscheiden, erzeugt PBuild hinter jeder Definition einen Bereich, der mit // $START-AUTODEPEND eingeleitet und mit // $STOP-AUTODEPEND beendet wird.

Einträge zwischen diesen beiden Merkern werden beim nächsten Aufruf PBuild /g ersetzt. Wer dort also eigene Anweisung einfügt, muss sie jedesmal wieder ergänzen. Daher: Finger weg von diesen Abschnitten!