Indy-Installation funktioniert nicht

[PeterPanino]

Zitat von jaenicke:

Es gibt eine eindeutige Fehlermeldung, deren Ursache logisch und leicht erklärt ist

Du hast also endlich eingesehen, dass die PRIMÄRE Ursache des Fehlers MSBUILD ist? "Primäre Ursache" bedeutet in diesem Zusammenhang, dass MSBUILD FAKTISCH den Fehler ausgibt - unabhängig davon, was man als sekundäre Ursache hinein interpretieren mag.

Deine vielen vergeblichen Versuche, die Anzahl der Library-Pfade als primäre Ursache festzumachen, muss ich anhand der Fakten als psychologischen Widerstand werten, der von dem bekannten Umstand abgeleitet wird, dass Menschen mit Vorurteilen oft große Schwierigkeiten haben, ihre Vorurteile und ihren Aberglauben aufzugeben. Solche Menschen festigen auch gemeinsam ihre Vorurteile, indem sie sich gegenseitig in ihrem Irrtum bestärken. Das sind alles wohlbekannte Symptome, die in vielen auch klinisch nachgewiesenen Situationen auftreten können. Wenn dich das Thema interessiert, kann ich dir gerne Links zu wissenschaftlichen Studien darüber zukommen lassen.

[mmw]

https://www.telefonseelsorge.de/

[jaenicke]

Zitat von PeterPanino:

Du hast also endlich eingesehen, dass die PRIMÄRE Ursache des Fehlers MSBUILD ist? "Primäre Ursache" bedeutet in diesem Zusammenhang, dass MSBUILD FAKTISCH den Fehler ausgibt - unabhängig davon, was man als sekundäre Ursache hinein interpretieren mag.

Du siehst das Problem des zu langen Bibliothekspfads nur, wenn du von außen versuchst, etwas zu kompilieren. Ob du dafür MSBuild nutzt oder nicht, spielt dabei keine Rolle, aber da du nur MSBuild verwendet hast, bekommst du auch nur dort den Fehler.

Das Tool selbst hat damit allerdings nichts zu tun, denn es tut nur das, was Embarcadero ihm sagt. Es sammelt die Kommandozeile nach den Vorgaben Embarcaderos zusammen und ruft diese dann auf. Nur dass das eben mit einem so langen Bibliothekspfad nicht geht.

Ich habe es einmal ausprobiert:
- Wenn nur ein Pfad mehr als die erlaubten 260 Zeichen hat, kompiliert die IDE selbst schon nicht mehr. Das ist hier also nicht das Problem.
- Ich habe dann den Bibliothekspfad aufgeblasen, indem ich immer wieder das gleiche Verzeichnis hinzugefügt habe. Daraufhin habe ich die oben genannte Fehlermeldung bekommen, was ja der absichtlich durch so viele Pfadangaben kaputten Konfiguration entspricht. Insofern passt da alles.

Dass die IDE selbst damit keine Probleme hat, ist auch klar, denn diese zeigt zwar die Kommandozeile an, ruft aber nicht die dcc32.exe auf (die es in Trials und der Community Edition ja nicht gibt), sondern verwendet direkt die Compiler-DLL und schiebt die Kommandozeile einfach direkt hinüber. Dass die Kommandozeile viel zu lang ist, sieht man aber dennoch in der IDE.

Und damit würde es auch ohne MSBuild nicht extern funktionieren, denn wenn man den Aufruf an die dcc32.exe aus der Registry selbst zusammenbauen würde, hätte man das gleiche Problem wie MSBuild. Das habe ich mit meinem entsprechenden Tool "Delphi Batch Compiler" auch ausprobiert. Der Aufruf des Compilers funktioniert dort mit derart vielen Bibliothekspfaden auch nicht. Ich bekomme die gleiche Fehlermeldung wie MSBuild, wenn ich versuche die dcc32.exe zu starten: "Der Dateiname oder die Erweiterung ist zu lang"

Wie gesagt:
Das Problem ist nicht MSBuild, sondern das Problem ist, dass du von extern versuchst zu kompilieren. Wenn du nur aus der IDE heraus kompilieren möchtest, kannst du alles lassen wie es ist. Willst du auch per Kommandozeile kompilieren, egal ob umständlich mit der dcc32.exe direkt oder mit MSBuild, dann klappt das mit einem so langen Bibliothekspfad nicht. (Es sei denn du schreibst die Pfade für jedes Projekt entsprechend deiner Umgebung selbst in die Kommandozeile. Aber der Aufwand steht in keinem Verhältnis zu einer Korrektur deines Bibliothekspfads.)

[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.