Indy-Installation funktioniert nicht

[PeterPanino]

Zitat von jaenicke:

Du siehst das Problem des zu langen Bibliothekspfads nur, wenn du von außen versuchst, etwas zu kompilieren.

Diese Aussage ist beweisbar FALSCH. Gib in einem Konsolenfenster diesen Befehl ein (Test.dpr existiert natürlich):

"C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\DCC32.EXE" "C:\DELPHI\Mein Test\Test.dpr"

Du erhältst eine wunderschöne Test.exe - und das trotz "zu vieler Library-Paths". Soeben getestet.

"Korrektur deines Bibliothekspfads."

Du hältst hartnäckig an deiner falschen Grundannahme fest, mein Bibliothekspfad müsse "korrigiert" werden. Auch das ist beweisbar falsch - außer du beweist mir das Gegenteil.

[jaenicke]

Damit bestätigst du genau, was ich geschrieben habe.

Wenn du natürlich keine Units aus dem Bibliothekspfad verwendest, musst du diese auch nicht angeben. Nichts anderes habe ich geschrieben.

Zitat von jaenicke:

(Es sei denn du schreibst die Pfade für jedes Projekt entsprechend deiner Umgebung selbst in die Kommandozeile.

Für dieses Projekt wird keiner benötigt, also hast du keinen angegeben.

Das kann aber ein Tool, das automatisch kompiliert, nicht herausfinden. Und deshalb klappt es eben nur, wenn du den Compiler manuell aufrufst, aber nicht mit einem Tool, das dies automatisch tut und eben alle Pfade einbeziehen muss.

Es ist ja alles gesagt. Du kennst die Lösung und spätere Leser des Threads auch. Ob du sie umsetzt oder nicht, ist deine Sache.

[dummzeuch]

Zitat von jaenicke:

Es ist ja alles gesagt. Du kennst die Lösung und spätere Leser des Threads auch. Ob du sie umsetzt oder nicht, ist deine Sache.

Ich bewundere Deine Geduld und wie Du in diesem Thread die Ruhe bewahrst.

[PeterPanino]

Zitat von jaenicke:

Nichts anderes habe ich geschrieben.

NEIN. Auch das ist falsch. Du hast geschrieben:

Zitat von jaenicke:

Du siehst das Problem des zu langen Bibliothekspfads nur, wenn du von außen versuchst, etwas zu kompilieren.

Wenn man bei der Compilierung "von außen", also bei der Verwendung von dcc32.exe, die benötigten Units in der Befehlszeile mit angibt, dann entsteht kein Problem.

Das Problem entsteht nur, wenn man MSBUILD verwendet, weil bei diesem Verfahren alle Bibliothekspfade übergeben werden.

Ich verstehe dich aber: Du hast dich an MSBUILD festgebissen und kannst nicht eingestehen, dass man bei der Verwendung von dcc32.exe und der Übergabe der benötigten Units kein Problem hat. Ist psychologisch verständlich.

[jaenicke]

Zitat von PeterPanino:

Das Problem entsteht nur, wenn man MSBUILD verwendet, weil bei diesem Verfahren alle Bibliothekspfade übergeben werden.

Ich verstehe dich aber: Du hast dich an MSBUILD festgebissen und kannst nicht eingestehen, dass man bei der Verwendung von dcc32.exe und der Übergabe der benötigten Units kein Problem hat. Ist psychologisch verständlich.

Ich verstehe durchaus, dass es von außen so aussieht, wenn man die logischen Zusammenhänge nicht versteht, die beim Kompilieren ablaufen. Deshalb mal ganz einfach:
Im Anhang liegt ein Demoprojekt. Dieses kompiliert nur, wenn man den ebenfalls beiliegenden Ordner lib in den Bibliothekspfad packt, sprich genau das nutzt, sofür dieser benötigt wird.

Im folgenden Screenshot siehst du, dass der Aufruf, wie du ihn als Beispiel genannt hast, fehlschlägt. Denn die Unit in dem Ordner lib kann der Compiler natürlich nicht finden. Danach verwende ich msbuild und in dem daraus erfolgenden Aufruf sieht man auch, dass der betreffende Bibliothekspfad dem Compiler übergeben wird. Mit MSBuild lässt sich das Projekt problemlos erstellen, eben weil es den Bibliothekspfad übergibt.

2023_03_19_12_21_17_Windows_PowerShell_cmd.jpg

Wie Delphi.Narium und ich schon geschrieben haben: Bei dir funktioniert es auch ohne den Bibliothekspfad, weil du den schlicht in deinem Test nicht nutzt. Sobald du aber ein Projekt hast, das diesen benötigt, klappt das nicht mehr.

Davon ganz abgesehen hat Delphi.Narium auch zu Recht die anderen Optionen angesprochen. Solche Geschichten wie verschiedene Buildkonfigurationen werden natürlich völlig ignoriert, wenn du nur die dcc32.exe ohne die entsprechenden Angaben aufrufst.

[PeterPanino]

Zitat von jaenicke:

Wie Delphi.Narium und ich schon geschrieben haben: Bei dir funktioniert es auch ohne den Bibliothekspfad, weil du den schlicht in deinem Test nicht nutzt. Sobald du aber ein Projekt hast, das diesen benötigt, klappt das nicht mehr.

Davon ganz abgesehen hat Delphi.Narium auch zu Recht die anderen Optionen angesprochen. Solche Geschichten wie verschiedene Buildkonfigurationen werden natürlich völlig ignoriert, wenn du nur die dcc32.exe ohne die entsprechenden Angaben aufrufst.

Vielen Dank für deine Mühe.

Kann es aber sein, dass du diesen Satz in meinem Posting übersehen hast:

"Wenn man bei der Compilierung "von außen", also bei der Verwendung von dcc32.exe, die benötigten Units in der Befehlszeile mit angibt, dann entsteht kein Problem."

[Delphi.Narium]

Zitat von PeterPanino:

Zitat von jaenicke:

Du siehst das Problem des zu langen Bibliothekspfads nur, wenn du von außen versuchst, etwas zu kompilieren.

Diese Aussage ist beweisbar FALSCH. Gib in einem Konsolenfenster diesen Befehl ein (Test.dpr existiert natürlich):

"C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\DCC32.EXE" "C:\DELPHI\Mein Test\Test.dpr"

Du erhältst eine wunderschöne Test.exe - und das trotz "zu vieler Library-Paths". Soeben getestet.

"Korrektur deines Bibliothekspfads."

Du hältst hartnäckig an deiner falschen Grundannahme fest, mein Bibliothekspfad müsse "korrigiert" werden. Auch das ist beweisbar falsch - außer du beweist mir das Gegenteil.

Was Du da angibst ist aber kein Bibliothekspfad, sondern nur der Pfad zur DPR. Und wenn die keine weiteren Units, Fremdkomponenten, Indys, ... einbindet, kann das Kompilieren durchaus gelingen.

Wenn die IDE oder MSBuild den Kompiler aufrufen, werden aber noch weitere Verzeichnisse übergeben, möglich wären da u. a.:

Code:

OutputDir
UnitOutputDir
PackageDLLOutputDir
PackageDCPOutputDir
SearchPath
Packages

Ebenso werden auf der Kommandozeile sämtliche in der IDE konfigurierten Kompileroptionen übergeben.

Gib doch bitte mal auf der Kommandozeile nur DCC32.exe an und schaue Dir die dort angegebenen Optionen an. Die werden alle von der IDE bzw. MSBuild an den Kompiler auf der Kommandozeile übergeben und wenn das alles "zuviel" wird, kommt der von Dir oben genannte Fehler.

Zitat von PeterPanino:

"C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\DCC32.EXE" "C:\DELPHI\Mein Test\Test.dpr"

ist also nichtmal die halbe Miete, sondern nur ein kleines Fragment der normalerweise übergebenen Kommandozeile.

Da weder IDE noch MSBuild wissen, welche der Optionen bzw. Pfade der Kompiler konkret benötigt, sie beide nicht wissen, wo ggfls. die benötigten Units zu suchen sind ..., müssen zwangsläufig alle konfigurierten Pfade und Optionen übergeben werden.

Wenn Deine Test.dpr keine Units aus den Suchpfaden benötigt, kannst Du ja der Einfachheit halber die Optionen zur Test.dpr in der IDE entsprechend konfigurieren, und schon wird auch per IDE bzw. MSBuild das Kompilieren gelingen.

Code:

Syntax: dcc32 [optionen] dateiname [optionen]

Letztlich entspricht Dein Aufruf "nur"

Code:

Syntax: dcc32 dateiname

und damit kann der Fehler, der durch zuviele Informationen in den Optionen hervorgerufen wird, nicht auftreten, da sie ja nicht angegeben wurden.