Indy-Installation funktioniert nicht

[jaenicke]

Zitat von PeterPanino:

Ich frage mich, wie andere große Delphi-Komponenten-Anbieter dies handhaben.

Man hat immer die Möglichkeit das ganze manuell über die dcc32.exe zu erledigen und das machen auch einige. Es ist zwar ein höherer Aufwand, weil man viel mehr Parameter mitgeben muss, die sonst aus der Projekt- und Delphikonfiguration gezogen werden, aber viele haben ihre Installer schon länger als es MSBuild in Delphi gibt und müssen daher nur jeweils eine neue Version von Delphi hinzufügen.
Andere liefern schlicht die kompilierten Dateien mit aus und packen die nur aus. Dann wird dabei gar kein Compiler benötigt.

Ein Vorteil von MSBuild ist auch, dass du mit MSBuild das gleiche Ergebnis bekommst wie mit der IDE (die intern ja ausschließlich MSBuild verwendet, nur eben ohne die dcc32.exe per Kommandozeile aufzurufen), während die dcc32.exe nur eine Teilmenge davon erledigt (keine Buildevents, keine Buildkonfigurationen, keine Plattformunterscheidung, kein Deployment, ...).

Klar ist: Delphi nutzt intern ausschließlich MSBuild, wenn du in der IDE kompilierst. Du kannst dort nicht die dcc32.exe direkt nutzen.

[PeterPanino]

Zitat von jaenicke:

wie mit der IDE (die intern ja ausschließlich MSBuild verwendet

Aber offenbar nur, wenn diese Flag gesetzt ist?

[PeterPanino]

Zitat von jaenicke:

Man hat immer die Möglichkeit das ganze manuell über die dcc32.exe zu erledigen und das machen auch einige.

Na, dann wäre das nach 5 Seiten Postings ja endlich mal geklärt. Schön, dass du das zugibst.

[Delphi.Narium]

Zitat von PeterPanino:

Zitat von jaenicke:

Man hat immer die Möglichkeit das ganze manuell über die dcc32.exe zu erledigen und das machen auch einige.

Na, dann wäre das nach 5 Seiten Postings ja endlich mal geklärt. Schön, dass du das zugibst.

Nur das weiter oben bereits steht:

Zitat von jaenicke:

Das hat mit MSBuild nichts (!) zu tun. Das ist nur ein schönes Tool, damit man die dcc32.exe nicht selbst aufrufen muss.

Daraus schließe ich, dass schon ein bisserl länger bekannt ist, dass das Kompilieren auch immer direkt per DCC32.exe möglich ist. Und zwar schon deutlich länger als Dein erster Versuch Deine test.dpr per DCC32 auf der Kommandozeile zu kompilieren.

[jaenicke]

Zitat von PeterPanino:

Zitat von jaenicke:

wie mit der IDE (die intern ja ausschließlich MSBuild verwendet

Aber offenbar nur, wenn diese Flag gesetzt ist?

Anhang 55914

Nein, das Flag gibt nur an, ob es extern (also als externes Programm) aufgerufen werden soll oder standardmäßig intern verwendet werden soll. Das Flag wurde eingeführt, weil bei sehr großen Projekten der Speicherverbrauch der IDE beim Kompilieren zu hoch wurde. Durch den externen Aufruf wurde der quasi in einen separaten Prozess ausgelagert.

Ohne MSBuild geht es aber nicht, was man ja auch an der Ausgabe beim Kompilieren in der IDE sieht. Das ist übrigens schon seit Delphi 2007 so. Da wurde auf die neue Buildengine umgestellt und dadurch wurden ja auch viele neue Features möglich.

Zitat von PeterPanino:

Na, dann wäre das nach 5 Seiten Postings ja endlich mal geklärt. Schön, dass du das zugibst.

Nichts anderes habe ich geschrieben. Du hast lediglich bestritten, dass der Fehler beim Aufruf von MSBuild aus der zu langen Liste deiner Bibliothekspfade resultiert, obwohl die Fehlermeldung genau das eindeutig sagt, und hast stattdessen behauptet, dass MSBuild fehlerhaft sei.

MSBuild funktioniert aber ja offensichtlich problemlos bei dir (wie du beim Kompilieren in der IDE merkst), nur dass es eben von Embarcadero so verwendet wird, dass beim externen Kompilieren der Compiler über die Kommandozeile aufgerufen wird und diese nun einmal limitiert ist.

[Thomasl]

Ist das schon in Delphi 11.3 drin?
https://github.com/IndySockets/Indy/...1d5b01b74dfac9

Dann braucht man die Indy ja nicht mehr tauschen.
Und die Neuen OpenSSL Dateien nur zusätzlich im Suchpfad hinzufügen

[jaenicke]

So schnell mahlen die Mühlen da nicht.
Da gibt es schon noch ein paar Änderungen an Indy, die bisher noch nicht mit Delphi mitgeliefert werden.

[PeterPanino]

Zitat von jaenicke:

Nichts anderes habe ich geschrieben.

NEIN. 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 ggf. nur (wenn paths.count > x), wenn man MSBUILD verwendet, weil bei diesem Verfahren alle Bibliothekspfade übergeben werden.

Ich verstehe dich aber: Du hast dich am Thema 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.

[PeterPanino]

Die Feldstudie zu meinem Lieblings-Thema war wieder mal ergiebig und unterhaltsam. Danke an alle Studien-Teilnehmer! :

[jaenicke]

Zitat von PeterPanino:

Das Problem entsteht ggf. nur (wenn paths.count > x), wenn man MSBUILD verwendet, weil bei diesem Verfahren alle Bibliothekspfade übergeben werden.

Das stimmt nur halb, denn egal ob bei meinem eigenen Tool oder anderen automatischen Paketinstallern:
Auch dort tritt das Problem auf.

Aber von mir aus hast du Recht:
Bei dir tritt es nur bei MSBuild auf, weil du die anderen nicht kennst und nutzt...

Das ist zwar nicht was du geschrieben hast, aber so war es ja offenbar gemeint.