Projekte mit Pbuild [ERLEDIGT]

Beitrag von **Manfred** » Mi, 11. Jan 2006 9:25

Moin,

noch ´ne Frage:

Mit den .XPJ Files können schön die Projekte verwaltet werden.

Soweit ich es aber jetzt sehe, geht das wohl nur, im Zusammenhang mit der Erzeugung von .EXE Files? Habe ich nicht die Möglichkeit nur die .PRG zu kompilieren, ohne eine .EXE zu erzeugen. Es wäre recht hilfreich, bei den ganzen Bibliotheken, die man sich zulegt. Die müssen ja nur als .OBJ vorliegen und nicht als .EXE. Habe ich hier irgendwas nicht verstanden, oder etwas überlesen? Ich habe m.E. noch nirgendwo etwas gefunden um nur .OBJ Files zu erzeugen, die aber in die Überprüfung von pbuild zu geben.

Ich hoffe ich habe jetzt nicht zu verworren geschrieben?

Beitrag von **Tom** » Mi, 11. Jan 2006 11:34

Hallo, Manfred.

Der Xbase-Compiler besteht aus drei Hauptkomponenten:

XPP - das ist der Compiler selbst, erzeugt aus PRG- OBJ-Dateien
ARC - der Ressourcen-Compiler, bindet Ressourcen ein
ALINK - der Linker, erzeugt EXE- bzw. DLL-Dateien

PBUILD sorgt lediglich dafür, daß alle Komponenten in der richtigen Reihenfolge ausgeführt werden (vereinfacht gesagt). Aus einer PRG-Datei eine OBJ-Datei erzeugen geht so:

XPP MeinCode.PRG

Beitrag von **Manfred** » Mi, 11. Jan 2006 11:47

Hallo Tom,

das war schon klar

. Ich meine, dass sollte ich schon wissen.

Ich wollte nur wissen, ob ich über ein Projektfile einfach nur die Objektdateien erzeugen kann, ohne eine EXE zu generieren

Beitrag von **Tom** » Mi, 11. Jan 2006 11:58

Hallo, Manfred.

Ich wollte nur wissen, ob ich über ein Projektfile einfach nur die Objektdateien erzeugen kann, ohne eine EXE zu generieren

Soweit ich weiß - nein. Aber sie entstehen ja immer. Es gibt also zwei Möglichkeiten:

1. Die (überflüssige?) EXE einfach löschen bzw. ignorieren
2. Einzelne OBJ-Dateien mit XPP erzeugen

Ich habe übrigens nicht ganz verstanden, wozu Du die OBJ-Dateien benötigst. Könntest Du das nochmal erläutern?

Beitrag von **Manfred** » Mi, 11. Jan 2006 12:07

Hi Tom,

Tom hat geschrieben:
Soweit ich weiß - nein. Aber sie entstehen ja immer. Es gibt also zwei Möglichkeiten:

1. Die (überflüssige?) EXE einfach löschen bzw. ignorieren
2. Einzelne OBJ-Dateien mit XPP erzeugen

Ich habe übrigens nicht ganz verstanden, wozu Du die OBJ-Dateien benötigst. Könntest Du das nochmal erläutern?

Ich habe es bisher immer so gemacht, dass ich mir dort meine eigenen Funktionen oder Klassen reinbaue, die ich auch in anderen Programmen benötige. Die liegen dann in einem getrennten Verzeichnis und werden mit eingebunden.

Beitrag von **Martin Altmann** » Mi, 11. Jan 2006 12:10

Hallo Manfred,
Du brauchst doch nur in jedem Projekt, in dem Du auch Sourcen aus Deinen "allgemeinen" prgs brauchst, diese prgs in die entsprechende .xpj-Datei mit aufnehmen!
Existieren sie schon als .obj, werden sie eingebunden, ansonsten erstmal kompiliert.

Viele Grüße,
Martin

Beitrag von **Manfred** » Mi, 11. Jan 2006 12:13

Hi Martin,

Martin Altmann hat geschrieben: Du brauchst doch nur in jedem Projekt, in dem Du auch Sourcen aus Deinen "allgemeinen" prgs brauchst, diese prgs in die entsprechende .xpj-Datei mit aufnehmen!
Existieren sie schon als .obj, werden sie eingebunden, ansonsten erstmal kompiliert.

hast Du das schon mal so gemacht? Hat es dann geklappt? Das war mit das 1. was ich probiert habe, aber dann schreibt er mir die OBJ Dateien ins aktuelle Verzeichnis, da sollen die aber nicht hin.

Beitrag von **Tom** » Mi, 11. Jan 2006 12:18

Dafür gibt es die Option OBJ_DIR:

Code: Alles auswählen

[PROJECT]
    COMPILE       = xpp
    COMPILE_FLAGS = /q /n
    DEBUG         = no
    GUI           = yes
    LINK_FLAGS    =
    RC_COMPILE    = arc
    RC_FLAGS      = -v
   OBJ_DIR       = \hycare
    OBJ_FORMAT    = COFF
    HYCARE.XPJ

Beitrag von **Manfred** » Mi, 11. Jan 2006 12:27

Tom hat geschrieben:Dafür gibt es die Option OBJ_DIR:

Code: Alles auswählen

[PROJECT]
    COMPILE       = xpp
    COMPILE_FLAGS = /q /n
    DEBUG         = no
    GUI           = yes
    LINK_FLAGS    =
    RC_COMPILE    = arc
    RC_FLAGS      = -v
   OBJ_DIR       = \hycare
    OBJ_FORMAT    = COFF
    HYCARE.XPJ

Stop stop stop,

vom reinen Gefühl her: schreibt er mir dann nicht alles in das Verzeichnis? Das soll er ja nicht. Ich möchte die Obj vom Hauptprogramm in einem VZ haben und die von den BIBs in einem anderen VZ. Also alles schön beamtenmäßig getrennt. So weit ich mich erinner, geht nur 1 oder kein, aber nicht verschiedene VZ.

Beitrag von **Jan** » Mi, 11. Jan 2006 13:00

Manfred,

darf ich mal fragen, was Du damit erreichen möchtest?

Ich arbeite selber auch mit der Pfadangabe für die .obj wie Tom das aufgeführt hat, aber die sind dann auch alle in diesem einen Verzeichnis. Mich stört das nicht im geringsten, daß da Programmspezifische, eigene Standard.obj, oder fremde obj drin sind.

Was ist Dein Problem damit? Vielleicht ist die Hilfe für Dich dann auch zielgerichteter.

Jan

Beitrag von **Tom** » Mi, 11. Jan 2006 13:04

Ich verstehe langsam, worum es geht. Du hast PRGs, die zum jeweiligen "Hauptprogramm" gehören und zusätzliche, die aus einer Art Pool stammen, also für jedes Deiner Hauptprogramme genutzt werden, richtig? Und diese letzteren sollen natürlich nicht jedes Mal compiliert werden.

Die OBJ-Dateien, die nicht in der AUTODEPEND-Sektion der XPJ-Datei angegeben sind, können mit diskreten Pfadangaben versehen werden.

Viel, viel eleganter wäre es aber m.E., Deine "übergreifenden" Funktionen in eine DLL zu stecken, die ein eigenes (!) Projekt ist. Auf diese DLL könntest Du dann aus allen anderen Projekten zugreifen, ohne daß da irgendwas gelinkt oder compiliert wird.

Beitrag von **Manfred** » Mi, 11. Jan 2006 13:10

Hi Jan,

Jan hat geschrieben:Manfred,

darf ich mal fragen, was Du damit erreichen möchtest?

Hm, naja, ich habe mir angewöhnt immer vorher alle OBJ Dateien zu einem Projekt zu löschen, bevor ich es kompiliere. Ind er Vergangenheit ist es mir irgendwie mehrer Male passiert, dass etwas falsch gelaufen ist und die OBJ Datei nicht neu erstellt wurde, obwohl sie es sollte.

Jetzt arbeite ich mit VX und finde es eigentlich nur recht schön, dass ich die entsprechende Meldung anklicke und schwupps im Code an der richgigen Stelle stehe. (es gibt noch mehr Gründe um VX zu benutzen) Deshalb benutze ich es auch um das gesamt Projekt direkt im Speicher zu haben.

Das Löschen vorher und komplett neu kompilieren kostet mich eigentlich von der Zeit nur ein müdes Lächeln, verzichte ich auf den Abgleich der Dateien.

Weiterhin möchte ich nicht unendlich viel OBJ DAteien von etlichen Projekten in einem Verzeichnis stehen haben.

Beitrag von **Jan** » Mi, 11. Jan 2006 13:12

Aber wo ist das Problem? Die werden bei einem inkrementellen Arbeiten ja auch nicht jedes Mal mit kompiliert. Sondern nur dann, wenn ich da etwas dran gearbeitet habe.

Abgesehen davon ist das mit der .dll natürlich viel eleganter. Unter Clippper hatte ich mir dafür immer eine eigene Lib erstellt. Das war sehr angenehm zu arbeiten, weil ich da dann auch Assembler-Funktionen mit reinbauen konnte. Dafür ist das nicht so flexibel, wenn ich dann doch einmal irgendetwas spezifisch anfassen möchte. Was aber dann an der universalitären Programmierung meiner eigenen Funktionen liegt ...

Und damit an meinem Willen, die Arbeit in diese Universalität reinzustecken.

Jan

Ups, jetzt war ich zu langsam. Deine Antwort kam vor meiner zu Toms Beitrag...

Wenn Du sicher sein willst daß wirklich alle obj kompiliet werden, dann nimm unter VX doch die Option "Rebuild Project". Die nehme ich ab und an auch, um die von Dir gewünschte Sicherheit zu haben.

Beitrag von **Manfred** » Mi, 11. Jan 2006 13:18

hier ist die Schlagzahl wieder gefährlich hoch....

an Jan und Tom...

Das mit den DLL.... gute Sache, nächste Sache. Habe ich versucht mich einzulesen,... kein Wort verstanden. Naja, vieleicht hätte ich mir doch mehr als 5 Minuten dafür Zeit nehmen sollen

Allerdings bin ich ehrlich, mich nervt es schon die DLL zum Programm als Runtimes mitzuliefern und darauf zu achten, das die immer passen. Insbesondere nach jedem Compilerwechsel, was ja in den letzten Wochen 1-2-3 Mal passiert ist.

Allerdings würde ich zumindest wissen wollen, wie das mit den DLL klappt. Also wie man so Dinger baut. Macht doch die späteren EXE Files auch kleiner, oder?

Beitrag von **Jan** » Mi, 11. Jan 2006 13:23

Wenn Du mit VX arbeitest kannst Du beim Start (jedenfalls wenn Du das nicht abgestellt hast) als Option wählen, ob Du eine dll erstellen willst. Ansonsten gibt es unter New die gleiche Option. Da packst Du dann die prg-Files rein, die Du da drin untergebracht haben möchtest. Und ab gehts.

Natürlich hast Du recht mit den Versionskonflikten, das nervt mich auch tierisch. Aber wann war das das letzte mal so hektisch wie in den letzten Wochen? Normalerweise kannst Du das dann jedesmal kurz durchlaufen lassen, wenn Du eine neue Xbase-Version bekommst, und dann ist erstmal wieder Ruhe. Ist schließlich immer nur eine einmalige Sache.

Jan

Beitrag von **Manfred** » Mi, 11. Jan 2006 13:29

Jan hat geschrieben:Wenn Du mit VX arbeitest kannst Du beim Start (jedenfalls wenn Du das nicht abgestellt hast) als Option wählen, ob Du eine dll erstellen willst. Ansonsten gibt es unter New die gleiche Option. Da packst Du dann die prg-Files rein, die Du da drin untergebracht haben möchtest. Und ab gehts.

Hm, ich habe VX eh nur zu einem Bruchteil verstanden. Die ganzen Parameter usw. Irgendwie habe ich auch noch nicht den Draht dazu gehabt, mich tiefer einzuarbeiten, bzw. die Dinge die ich ausprobiert hatte, die klappten nicht richtig und die habe ich dann dem Support weitergereicht. (Der kümmert sich noch

)

Natürlich hast Du recht mit den Versionskonflikten, das nervt mich auch tierisch. Aber wann war das das letzte mal so hektisch wie in den letzten Wochen? Normalerweise kannst Du das dann jedesmal kurz durchlaufen lassen, wenn Du eine neue Xbase-Version bekommst, und dann ist erstmal wieder Ruhe. Ist schließlich immer nur eine einmalige Sache.

Da hast Du mich falsch verstanden, es geht um die DLL´s vor Ort, beim Benutzer. Das hieße für mich, ich müßte noch mehr kontrollieren, was denn nun an DLL ausgetauscht werden müßte, weil die Zusatzlibs von meiner Seite auch immer wieder angepaßt werden.

Beitrag von **Jan** » Mi, 11. Jan 2006 13:37

Manfred hat geschrieben: Das hieße für mich, ich müßte noch mehr kontrollieren, was denn nun an DLL ausgetauscht werden müßte

Was hast denn Du für eine Vorgehensweise bei Updates? Wenn Du z. B. die persönliche DLL in dem Programmverzeichnis hast, dann wird die doch bei einem Update automatisch mit der neuen überschrieben. Oder habe ich da etwas falsch verstanden?

Jan

Beitrag von **Jan** » Mi, 11. Jan 2006 13:41

Manfred hat geschrieben:Weiterhin möchte ich nicht unendlich viel OBJ DAteien von etlichen Projekten in einem Verzeichnis stehen haben.

Das verstehe ich jetzt nicht. Hast denn Du nicht für jedes Projekt eine eigene Verzeichnis-Struktur?

Jan

Beitrag von **Manfred** » Mi, 11. Jan 2006 13:42

Was hast denn Du für eine Vorgehensweise bei Updates? Wenn Du z. B. die persönliche DLL in dem Programmverzeichnis hast, dann wird die doch bei einem Update automatisch mit der neuen überschrieben. Oder habe ich da etwas falsch verstanden?

Ok, nochmal von vorne

ich meine die DLL´s, die ich an den Benutzer mit herausgebe, die dann meinen PC verlassen. Wenn ich nun die DLL ändere, dann muß ich entweder an jeden die DLL mitschicken pauschal, oder aber jedesmal prüfen, oder nachdenken, wer sie denn jetzt bekommen müßte. Das Erstellen einer neuen DLL ist sicher kein Problem, aber das Verwalten vor Ort, stelle ich mir entsprechend vor.
Wenn ich den ganzen Sermon bei mir direkt mit kompiliere, in die fertige EXE Datei, dann habe ich nur die Sorge(n) mit den Runtimelibs, die von Alaska mitkommen. Und das ist m.E. schon genug.

Unter Clipper war alles leichter, snieef.

Aber wir wollen ja den Fortschritt akzeptieren.

Beitrag von **Tom** » Mi, 11. Jan 2006 13:45

Hallo, Manfred.

Mmmh. Du hast PRGs (es gibt übrigens keinen Plural-Apostroph, nicht einmal in Amerika - DLLs usw. schreibt man ohne!), die von mehreren Anwendungen genutzt werden, Du willst aber nicht, daß jede Anwendung die OBJ-Dateien erzeugt und Du willst alles in einer EXE, damit es keine Versionskonflikte in anderen Programmen gibt, wenn Du aus einem heraus eine neue DLL erzeugst, richtig? Hilft meines Erachtens ein einfaches :

Code: Alles auswählen

#include '\gemeinsame prgs\gemeinsam.prg'

am Anfang jedes Hauptprogrammes. Auf diese Art werden keine OBJ-Dateien erzeugt.

Beitrag von **Manfred** » Mi, 11. Jan 2006 13:45

Jan hat geschrieben:
Manfred hat geschrieben:Weiterhin möchte ich nicht unendlich viel OBJ DAteien von etlichen Projekten in einem Verzeichnis stehen haben.
Das verstehe ich jetzt nicht. Hast denn Du nicht für jedes Projekt eine eigene Verzeichnis-Struktur?

Jan

doch doch, aber ein Projekt besteht aus meheren einzelnen EXE Files. Das habe ich schon schwer zusammengeschrumpft, aber ich finde das bestimmte Teile in bestimmten Programme nichts zu suchen haben. Unter Clipper hatte ein Projekt bis zu 10 Programme, schon aus RAM Speichergründen. Und dann gibt es halt auch entsprechend viele VZ. Alle, aber auch wirklich alle, egal welches Projekt, greifen nun einmal auf bestimmte feste Routinen zurück.

Beitrag von **Jan** » Mi, 11. Jan 2006 13:47

Ich bin jetzt mal eher vage. Ich glaube mich erinnern zu können, daß Dir da mit einer statischen statt einer dynamischen DLL geholfen werden könnte. Die nämlich mit in die Exe eingebunden wird. Aber da hoffe ich mal, daß irgendwelche Spezies auf dem Gebiet besser Auskunft geben können.

Ansonsten: Ich habe das für ein Projekt gemacht, daß ich für jeden Kunden ein eigenes Verzeichnis erstellt habe. Wo alle Dateien reinkommen, die ich ihm mitgeliefert habe. Das ist garnicht so aufwendig, und ich habe da immer alles unter Kontrolle.

Jan

Beitrag von **Manfred** » Mi, 11. Jan 2006 13:49

Hallo Tom,

Tom hat geschrieben:Hallo, Manfred.

Mmmh. Du hast PRGs (es gibt übrigens keinen Plural-Apostroph, nicht einmal in Amerika - DLLs usw. schreibt man ohne!),

stimmt, sowas blödes, es gibt ja auch keine CD´s.

die von mehreren Anwendungen genutzt werden, Du willst aber nicht, daß jede Anwendung die OBJ-Dateien erzeugt und Du willst alles in einer EXE, damit es keine Versionskonflikte in anderen Programmen gibt, wenn Du aus einem heraus eine neue DLL erzeugst, richtig? Hilft meines Erachtens ein einfaches :
Code: Alles auswählen
#include '\gemeinsame prgs\gemeinsam.prg'
am Anfang jedes Hauptprogrammes. Auf diese Art werden keine OBJ-Dateien erzeugt.

Holla die Waldfee, habe ich auch schon unter Clipper probiert, habe ich auch nie hinbekommen.

Man muß ich jetzt einen doofen Eindruck hier hinterlassen....

Beitrag von **Tom** » Mi, 11. Jan 2006 13:55

Hallo, Manfred.

Man muß ich jetzt einen doofen Eindruck hier hinterlassen....

Mitnichten. Ich find's auch gut und richtig, daß vermeintliche 'Basics'-Fragen gestellt werden. Viele trauen sich vielleicht nicht, sowas zu fragen, lernen aber kräftig mit. Und man kann einfach nicht alles wissen. Ich würde darauf wetten, daß es für jeden von uns Ecken in Xbase gibt, die er noch nicht aufgestöbert hat, die aber sein Leben stark vereinfachen würden.

Beitrag von **Manfred** » Mi, 11. Jan 2006 13:59

Tom hat geschrieben:Hallo, Manfred.

Man muß ich jetzt einen doofen Eindruck hier hinterlassen....
Mitnichten. Ich find's auch gut und richtig, daß vermeintliche 'Basics'-Fragen gestellt werden. Viele trauen sich vielleicht nicht, sowas zu fragen, lernen aber kräftig mit. Und man kann einfach nicht alles wissen. Ich würde darauf wetten, daß es für jeden von uns Ecken in Xbase gibt, die er noch nicht aufgestöbert hat, die aber sein Leben stark vereinfachen würden.

auh weiah, ich vermute wohl, dass es bei mir so viele Ecken sind, dass es schon wieder ein Kreis wird....

Aber wie sagt der Kölner immer? Bis jätz haddet immer noch alles jut jejangen.