Pbuild: Unterschied zwischen den Versionen

Aus Wiki des Deutschsprachige Xbaseentwickler e. V.
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „PBuild ist der ProjectBuilder von Alaska Software. PBuild steht in der Tradition eines make unter Unix. Unter Xbase++ dient PBuild sowohl der Erstellung einer…“)
 
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).
Zeile 5: Zeile 5:
----
----


Wie erstellt man eine Projekt-Definitions-Datei (Erweiterung .xpj)?
==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.
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.
Zeile 14: Zeile 14:


wobei PBuild in diesem Fall einige "Vermutungen" anstellt über die Art des Programms:
wobei PBuild in diesem Fall einige "Vermutungen" anstellt über die Art des Programms:
==Aufbau einer Projekt-Datei==


  [PROJECT]
  [PROJECT]
Zeile 29: Zeile 33:


----
----
COMPILE = xpp
 
==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.
legt fest, dass als Compiler xpp.exe aufgerufen werden soll. Ein abweichender Eintrag macht keinen Sinn.


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


----
----
DEBUG = yes
DEBUG = yes
aktiviert die Debugging-Unterstützung
aktiviert die Debugging-Unterstützung


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


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


----
----
LINK_FLAGS =
LINK_FLAGS =
Im Standard erhält ALink keine weiteren Schalter.
Im Standard erhält ALink keine weiteren Schalter.


----
----
RC_COMPILE = arc
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.
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
RC_FLAGS = /v
übergibt /v als Schalter an arc.exe (wobei /v für "verbose mode" steht).
übergibt /v als Schalter an arc.exe (wobei /v für "verbose mode" steht).


----
----
PBUILD = @project.txt
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.


MAKE =  
----
OBJ_FORMAT=COFF/OMF


----
----
POST_BUILD=


PROJECT.XPJ
----
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!

Version vom 30. April 2013, 21:49 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!