PBuild, DLLs und die Panik

[georg]

Hallo,


inzwischen nervt mich ein Feature von PBuild ...

Es geht um ein Programm, damit mit etlichen DLLs erweitert wird. Für jeden Anbieter existiert eine separate DLL, da die verschiedenen Anbieter unterschiedliche Schnittstellen verwenden. Auf diese Art und Weise kann ich dann in der jeweiligen DLL auf die Besonderheiten eingehen.

Das Programm ruft die DLL per DLLCall auf, also nicht per direktem Funktionsaufruf. Die XPJ sieht etwa so aus:

Code: Alles auswählen

[PROJECT]
    COMPILE       = xpp
    COMPILE_FLAGS = /p /q /w /wl /wu
    DEBUG         = yes
    GUI           = yes
    LINKER        = alink
    LINK_FLAGS    = /PM:PM
    RC_COMPILE    = arc
    RC_FLAGS      = /v
    PROJECT.XPJ

[PROJECT.XPJ]
   ANBDLL01.DLL
   ANBDLL02.DLL
   ANBDLL03.DLL
   ...
   MAIN.EXE

[ANBDLL01.DLL]
   ANBDLL01.PRG

...

[MAIN.EXE]
   MAIN.PRG
   NOTSOMAIN.PRG
   ...

Wenn ich jetzt in einer DLL etwas ändere und PBuild laufen lasse, wird die entsprechende .PRG Datei compiliert. Danach aber kommt für jede der definierten DLLs diese Meldung:

Code: Alles auswählen

DLL ANBDLL99.DLL created successfully.
alink @C:\Users\Georg\AppData\Local\Temp\01010411.tmp
Alaska 32-Bit Linker Version 1.90.355
Copyright (c) Alaska Software 1997-2009. All rights reserved.

Durch die schiere Menge der DLLs verschwinden langsam die Meldungen der Compilierung aus dem Fenster (und sind bald selbst durch Scrollen nicht mehr erreichbar). Wie bringe ich PBuild bei, dass die DLLs "standalone" sind und nicht jedes mal angepackt werden müssen, wenn eine von ihnen verändert wird?

Mitten zwischendrin (!) kommt dann auch diese Meldung:

Code: Alles auswählen

MAIN.EXE created successfully.
alink @C:\Users\Georg\AppData\Local\Temp\01010813.tmp
Alaska 32-Bit Linker Version 1.90.355
Copyright (c) Alaska Software 1997-2009. All rights reserved.

Auch die Reihenfolge der Einträge unter PROJECT.XPJ hat keinen Einfluss, da scheint PBuild /G sogar noch nach irgendwelchen Kriterien umzusortieren.

Hat einer von Euch einen Vorschlag, was ich machen kann?

[AUGE_OHR]

hi,

ein frohes neues Jahr 2013

gibst du in den DLL Sektionen LIBs von anderen DLL an ?

[georg]

Hallo, Jimmy -


in den jeweiligen Abschnitten liste ich nur die .PRG Dateien.

Die DLLs, die ich hier erstelle, greifen auch nicht über #PRAGMA auf andere DLLs zu.

[UliTs]

Ich vermute, dass das Auflisten der DLLs hinter [PROJECT.XPJ] ueberfluessig ist.

Code: Alles auswählen

[PROJECT.XPJ]
   ANBDLL01.DLL
   ANBDLL02.DLL
   ANBDLL03.DLL
   ...
 

Uli

[Tom]

Eben. Eigene XPJ für die austauschbaren DLLs, und nur die entstandenen LIBs (!) per #pragma-Direktive einbinden, ggf. über #ifdef für die kunden-/versionsspezifischen Nutzungen. Dann muss man auch nicht mit DLLCall arbeiten - sondern kann direkt auf die Funktionen zugreifen. Im XPJ für die Hauptapplikationen haben die DLLs nichts zu suchen - sie wären in der DLLCall-Variante auch überflüssig, denn in dieser Struktur muss PBUILD die DLLs beim Linken nicht kennen.

[georg]

Hallo,


also werde ich wohl mit zwei XPJ operieren müssen. Das kommt meinem Trend, faul zu sein, nicht sonderlich entgegen.

Zur Erklärung: die DLLs werden NICHT über #PRAGMA eingebunden, sondern über einen Satz aus einer Schnittstellendefinitionsdatei aufgerufen. Wenn ich die DLLs per #PRAGMA einbinde, muss ich sie auch alle ausliefern, was auch bestimmten Gründen nicht erwünscht ist.

Mal sehen, ob sich mein zweites Problem dann auch erübrigt. Erst einmal vielen Dank!

[Hans Zethofer]

vielleicht könnte man ja einmal einen Satz verschiedenster XPJ für verschiedenste Anwendungen zum Studium in die Wissensdatenbank stellen.
Verbessern kann man dabei sicher immer noch einiges in den eigene Projektfiles - wäre vielleicht auch für andere zur Analyse hilfreich!

[brandelh]

Ich nutze häufig eine XPJ Datei für verschiedene EXE Dateien und wenn ich eine PRG oder CH Datei ändere wird nur kompiliert was davon abhängt.
DLLs nutze ich zwar nicht, aber irgendwo müssen da Querverbindungen in der XPJ Datei stehen.

[georg]

Hallo,


erst einmal "danke" für die vielen Hinweise und Ratschläge. Ich habe inzwischen zwei XPJ Dateien, aber mein GRUNDPROBLEM besteht weiterhin:

wenn ich eine der Quell-Dateien für die DLLs ändere und NUR DIE DLLS durch PBuild laufen lasse, passiert folgendes:

1. der geänderte Quelltext wird compiliert - wird so erwartet und ist auch in Ordnung
2. JEDE der DLLs wird im nächsten Schritt neu erzeugt, und das, obwohl keine Querbeziehung besteht (die DLLs rufen sich nicht gegenseitig auf)

Der 2. Schritt ist es, der mir Kopfzerbrechen bereitet. Grundsätzlich, weil ich auf der Kommandozeile operiere, und selbst bei einem Zeilenpuffer von 300 Zeilen irgendwann der Zeitpunkt kommt, wo die Compile-Meldungen der geänderten Quelle aus dem Fenster rausfallen. Zum anderen, warum werden die DLLs alle neu erstellt, obwohl bei n-1 DLLs GAR NICHTS geändert wurde?

Es gibt natürlich noch den Weg, für jede DLL eine einzelne XPJ Datei anzulegen, aber dann sind wir doch wieder bei den Kompilierbatches, die wir vor MAKE hatten, und da will ich nun auch nicht hin.

[Koverhage]

Warum dann nicht
PBUILD PROJECT >compile.txt

[georg]

Hallo, koverhage -


weil ich die dann auch wieder im Editor öffnen muss.

Von einer MAKE-Utility (und als solche stufe ich PBuild ein), erwarte ich, dass NUR das betroffene Objekt compiliert bzw. gelinkt wird, und die anderen NICHT angepackt werden.

Und da es keine Querverbindung zwischen den einzelnen DLLs gibt (ausser, dass sie unter PROJECT.XPJ gelistet sind), dürften die anderen 14 DLLs bei der Änderung einer DLL nicht angepackt werden.

Aber PBuild erstellt alle (derzeit) 15 DLLs bei dem Durchlauf neu.

DAS ist das Problem. Alles andere betrifft nur meine Faulheit.

[georg]

Hallo,


um's mal verständlich zu machen:

Code: Alles auswählen

Demo01.prg:
#INCLUDE "AppEvent.CH"
#INCLUDE "Xbp.CH"

FUNCTION Demo01()
RETURN (.T.)

Das gleiche Programm gibt es dann 8 mal. Die Project.XPJ sieht wie folgt aus:

Code: Alles auswählen

//
// Project - Definition - File created by PBUILD Version  1.90.355
// Date: 03.01.2013 Time: 14:16:18
//

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

[PROJECT.XPJ]
    DEMO01.DLL
    DEMO02.DLL
    DEMO03.DLL
    DEMO04.DLL
    DEMO05.DLL
    DEMO06.DLL
    DEMO07.DLL
    DEMO08.DLL

[DEMO01.DLL]
// $START-AUTODEPEND
    DEMO01.OBJ
    STD.CH
    SET.CH
    NATMSG.CH
    GET.CH
    PROMPT.CH
    MEMVAR.CH
    COLLAT.CH
    APPEVENT.CH
    XBP.CH
    DEMO01.DEF
    DEMO02.LIB
    DEMO03.LIB
    DEMO04.LIB
    DEMO05.LIB
    DEMO06.LIB
    DEMO07.LIB
    DEMO08.LIB
// $STOP-AUTODEPEND
    DEMO01.PRG

Und das ganze wiederholt sich dann sieben mal. Unter Betrachtung der Auto-Abhängigkeiten, die PBuild unterstellt, wird das "rätselhafte" Verhalten deutlicher:

Code: Alles auswählen

    DEMO02.LIB
    DEMO03.LIB
    DEMO04.LIB
    DEMO05.LIB
    DEMO06.LIB
    DEMO07.LIB
    DEMO08.LIB

Was PBuild zu der Annahme bringt, dass die DLLs etwas miteinander zu tun haben, kann ich nicht nachvollziehen, da der Quelltext (siehe oben) nicht zu dieser Annahme führen kann.

Von diesem Punkt aus ist aber das Verhalten von PBuild klar: wenn Demo01.LIB geändert wird, müssen die anderen DLLs auch angepasst werden. Das dies keine Endlosschleife gibt, ist schon erstaunlich ...

Problem identifiziert, wenn auch nicht gelöst. Ich werde wohl nach jedem "pbuild /g" die XPJ-Datei editieren müssen, aber damit kann ich leben.

[brandelh]

genau, diese LIB Einträge verursachen die "Querverbindung", da diese im Quellcode der PRG nicht aufgeführt werden
ist das wohl ein BUG oder ein FEATURE je nach Auslegung

PS: ich ändere auch immer die Projektdatei nach /G, da diese (neben DEBUG und GUI) die EXE immer in GROßBUCHSTABEN schreiben, das gefällt mir nicht

[Tom]

Du hast eine XPJ für alle DLLs, und jede DLLs enthält die LIBs der jeweils anderen als Cross-Referenz, so dass jede DLL im Prinzip dazu in der Lage wäre, ohne Weiteres alle Funktionen aller anderen DLLs zu nutzen. Nun ändert sich eine DLL, somit auch die LIB, die in den jeweils anderen Sektionen referenziert ist. Klar, dass dann alle DLLs neu gebaut werden müssen, denn die Referenzen auf die anderen DLLs werden in sie eingebaut.

Wenn ich Dich aber richtig verstehe, sind die acht DLLs gegeneinander austauschbar. Es hat also überhaupt keinen Sinn, in ihnen die jeweils 7 anderen zu referenzieren. Warum tust Du das? Und was soll die Referenz auf das jeweils eine .DEF-File? Das hat überhaupt keinen Sinn.

[georg]

Hallo, Tom -


wenn Du genau hinsiehst, stellst Du fest, dass die Referenzen durch ein "pbuild /G" eingefügt wurden, darum stehen sie auch nach // $START-AUTODEPEND. ICH habe es nicht getan, zumindest nicht direkt, oder eher indirekt, durch Aufruf von "pbuild /g".

Darum ja auch das kleine Progrmmbeispiel in meinem Beitrag, das klar zeigt, dass keinerlei Referenz zu den anderen DLLs besteht.

Allerdings war/ist mein Ausgangsprojekt deutlich grösser, und es werden mehr Referenzen erzeugt, weshalb mir diese Referenzen dort nicht aufgefallen sind.

[Tom]

Hallo, Georg.

Wie auch immer - um so zu verfahren, wie Du das willst, benötigst Du in der Autodepend-Sektion der jeweiligen DLL nur ihr eigenes PRG. Und keine LIB-Verweise auf die anderen DLLs. Dann sollte PBUILD auch immer nur das neu bauen, was sich geändert hat.