Indy-Installation funktioniert nicht

[blawen]

Zitat von PeterPanino:

Das scheint ein allgemeines Problem bei MS Build zu sein:
...
Auch TMS verwendet MS BUILD zum Installieren seiner Komponenten - dort tritt dann der gleiche Fehler auf (Befehlszeile zu lang). Die TMS-Komponenten müssen dann umständlich manuell in der IDE installiert werden!...

Manuell kompilieren muss man nichts, lediglich den Namen des Installationspfades kürzen.

Das Hauptproblem bei den TMS Komponenten ist, dass TMS sehr grosszügig mit der Länge des Pfades und der Namenslänge der Packages umgeht. Diesbezüglich gibt es mehrere Einträge, wie z.B. den hier oder hier von 2014.

Seitdem ich den Pfad massiv eingekürzt habe, z.B. C:\T\FNC\UI, habe ich diesbezüglich keine Probleme mehr.

[PeterPanino]

Zitat von blawen:

Seitdem ich den Pfad massiv eingekürzt habe, z.B. C:\T\FNC\UI, habe ich diesbezüglich keine Probleme mehr.

Ich frage mich, wie andere große Delphi-Komponenten-Anbieter dies handhaben. Zum Beispiel schaffen es DevExpress, ImageEn und ShellBrowser (Jam Software) - um nur einige wenige zu nennen - ihre riesigen Komponentenbibliotheken ohne Pfadprobleme zu installieren. Welche Tricks verwenden sie? Was macht TMS anders? (Als ich einmal Bruno Fierens darauf ansprach, meinte er, er verwende MSBUILD aufgrund einer Empfehlung).

Übrigens: Wie verkürzt du den Installationspfad bei bereits vorhandenen Installationen?

Und übrigens: Beim zweiten der von dir zitierten Postings geht es um Pfade in den Environment-Variablen. Der Poster hat natürlich recht: Auch dort kann man Platz einsparen.

[Delphi.Narium]

Zitat von blawen:

TMS sehr grosszügig mit der Länge des Pfades

Die haben einfach sehr lange Pfadnamen und sehr lange Dateinamen. Und wenn man viele Verzeichnisse mit langen Namen hat und diese alle zum Suchpfad hinzufügen muss, dann sind irgendwann die 32000 Zeichen voll. Und wenn man dann neben TMS noch Indy, JCL, JVCL, DevExpress, ImageEN (abgesehen von den Pfaden, die für die delphieigenen Units benötigt werden) installiert hat, kann da der Platz schonmal knapp werden. Und wenn dann der Pfad, unterhalb dessen man seine Delphiprojekte ablegt hat (z. B. C:\Users\MeinNameIstAuchNichtSoKurz\AppData\Local\ Delphi\), auch nicht unbedingt kurz ist, dann wird es über eher kurz als lang knapp.

Deshalb hab' ich mit angewöhnt alle Units, die ich in einem Projekt benötige, in das Projekt aufzunehmen. Das macht die DPR zwar nicht gerade übersichtlicher, aber der Suchpfad hält sich in Grenzen, der Kompiler muss nicht jedesmal den ganzen Suchpfad "abklappern", um jede einzelne Unit zu finden, was den "netten" Nebeneffekt hat, dass das Kompilieren deutlich schneller werden kann, da in der DPR für alle dort aufgeführten Units bereits steht, wo sie konkret zu finden sind.

Zitat von PeterPanino:

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

Dazu hab' ich von Dir kein konkretes Beispiel gesehen. Meine DCC32.exe bietet keine Möglichkeit, jede einzelne benötigte Unit einzeln per Kommandozeile zu übergeben.

Zeig' uns doch bitte mal den Kommandozeilenaufruf von DCC32.exe für das Projekt, bei dem der o. g. Fehler auftrat,

Code:

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

enthält jedenfalls keine Unitangaben in der Kommandozeile, sondern nur den Namen des zu kompilierenden Projektes.

[PeterPanino]

Zitat von Delphi.Narium:

enthält jedenfalls keine Unitangaben in der Kommandozeile, sondern nur den Namen des zu kompilierenden Projektes.

Für einfache Projekte, die nur Standard-Komponenten enthalten, kommt man damit aus. Ich habe z.B. diese VCL-Application mit ein paar Standard-Komponenten zusammengeklickt und dann mit dcc32.exe ohne Pfadangaben compiliert:

standard.png

Man könnte dann z.B. Folgendes machen: Das UI-Design und die Funktionalität der gewünschten App mit Standard-Komponenten von einer AI erstellen lassen und dann per Befehlszeile die Exe compilieren: Voilà - ein fertiges Programm in 30 Sekunden.

[Delphi.Narium]

Das von Dir eingangs genannte Problem tritt aber doch eben nicht mit Standardkomponenten auf, sondern bei der Installation der Indykomponenten.

Packe doch bitte mal auf Dein Projekt noch eine Komponenten von den Indys.

Funktioniert das Kompilieren per DCC32 dann immernoch?

Oder alternativ beim Hinzufügen einer Komponente von ImageEN?

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

msbuild.png

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