Indy-Installation funktioniert nicht

[PeterPanino]

Zitat:

Zitat von jaenicke (Beitrag 1520046)

fehlerhafte Konfiguration

Die Grundannahme "fehlerhafte Konfiguration" ist die Ursache deines Denkfehlers. Oft basieren falsche Grundannahmen auf "Glauben". Glauben ist aber keine logische Kategorie. Nur Aussagen, die man beweisen kann, sind eine logische Kategorie, mit der man rechnen kann.

In der Religion wird "falscher Glauben" auch als Aberglauben bezeichnet. In der Logik ist Glauben aber immer Aberglauben.

[jaenicke]

Ich sehe keinen Grund, an einer so präzisen Fehlermeldung eines Standardwerkzeugs wie MSBuild zu zweifeln, bis man die Angabe überprüft hat.

Wenn du das nicht prüfen möchtest, ist das deine Sache. Dafür kann aber weder Delphi noch MSBuild oder das Indy-Projekt etwas. Dann kann dir leider auch niemand dabei helfen.

// EDIT:

Zitat:

Zitat von PeterPanino (Beitrag 1520045)

Die Logik ist eigentlich ganz einfach und sollte eigentlich von jedem Grundschüler verstanden werden:

Delphi-Quellcode:

if CompilationByMSBUILD and (LibraryPaths.Count > X) then
  Result := Error
else if CompilationByDCC32 then
  Result := OK;

Gestern bin ich in einem Mercedes bei Glatteis über die Landstraße gefahren, da war alles in Ordnung. Heute bin ich mit einem VW bei Glatteis gefahren und bin an einen Baum gefahren. VW ist Mist.

Ja, Logik ist oft einfach, aber man sollte nicht Ursache und Wirkung durcheinander bringen.

[PeterPanino]

Zitat:

Zitat von jaenicke (Beitrag 1520048)

Heute bin ich mit einem VW bei Glatteis gefahren und bin an einen Baum gefahren. VW ist Mist.

Do solltest nicht Logik mit kindlicher Logik verwechseln.

Ich frage mich oft, was der tatsächliche Grund für die fast als religiös zu bezeichnende Verzücktheit ist, mit der viele Leute an Microsoft-Produkten hängen.

[PeterPanino]

Zitat:

Zitat von jaenicke (Beitrag 1520048)

Ich sehe keinen Grund, an einer so präzisen Fehlermeldung eines Standardwerkzeugs wie MSBuild zu zweifeln, bis man die Angabe überprüft hat.

In der Akustik könnte man eine solche Aussage als "Gaußsches weißes Rauschen" bezeichnen.

[jaenicke]

Zitat:

Zitat von PeterPanino (Beitrag 1520050)

Ich frage mich oft, was der tatsächliche Grund für die fast als religiös zu bezeichnende Verzücktheit ist, mit der viele Leute an Microsoft-Produkten hängen.

Was hat denn der Hersteller des Tools damit zu tun? Es gibt eine eindeutige Fehlermeldung, deren Ursache logisch und leicht erklärt ist. Und nach deinen Äußerungen hast du das ja offenbar auch nicht überprüft.

Verstehe ich das richtig? Die Fehlermeldungen gefallen dir nicht und du glaubst ihnen nicht, weil es ein Microsoft-Tool ist? Und dann fängst du mit religiöser Verzücktheit an? Sorry, aber worüber reden wir hier eigentlich?

[PeterPanino]

Zitat:

Zitat von jaenicke (Beitrag 1520053)

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:

Zitat von PeterPanino (Beitrag 1520054)

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:

Zitat von jaenicke (Beitrag 1520056)

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:

Zitat von jaenicke (Beitrag 1520056)

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