Indy-Installation funktioniert nicht

[PeterPanino]

Ich habe das neueste Indy-Paket heruntergeladen von:
https://github.com/IndySockets/Indy

Da ich Delphi 11 verwende, habe ich \Lib\Fullc_Alexandria.bat ausgeführt. Die Fehlermeldung ist aber unverständlich:

C:\Program Files (x86)\Embarcadero\Studio\22.0\Bin\CodeGear.Delphi. Targets(412,5): warning MSB6002: The command-line fo
r the "DCC" task is too long. Command-lines longer than 32000 characters are likely to fail. Try reducing the length of
the command-line by breaking down the call to "DCC" into multiple calls with fewer parameters per call. [C:\COMP\Indy-
master\C28\IndySystem280.dproj]
C:\Program Files (x86)\Embarcadero\Studio\22.0\Bin\CodeGear.Delphi. Targets(412,5): error MSB6003: The specified task ex
ecutable "dcc" could not be run. The filename or extension is too long [C:\COMP\Indy-master\C28\IndySystem280.dproj]
Done Building Project "C:\COMP\Indy-master\C28\IndySystem280.dproj" (Rebuild target(s)) -- FAILED.

Wie kann aber die Befehlszeile für die Installation von Indy länger als 32.000 Zeichen sein?

Wenn ich aber dann aber \C28\IndySystem280.dproj in Delphi 11 lade und manuell zu compilieren versuche, kommt diese Fehlermeldung:

[Fatal Error] Cannot compile package 'IndySystem280' which is currently required by Delphi 11.

Was ist damit gemeint?

[jaenicke]

Die Fehlermeldung heißt normalerweise, dass du zu viele Pfade in deinem Bibliothekspfad hast.

Wird die zu lange Kommandozeile gar nicht erst angezeigt?

[PeterPanino]

Wieso übergibt das Script in der Befehlszeile überhaupt ALLE Library-Paths an den Delphi Befehlszeilen-Compiler DCC32? Das ist doch völlig unlogisch und unnötig - es soll doch nur das Indy-Package compiliert werden!

Auch die Fehlermeldung "[Fatal Error] Cannot compile package 'IndySystem280' which is currently required by Delphi 11." ist unlogisch da in sich widersprüchlich.

[jaenicke]

Zitat von PeterPanino:

Wieso übergibt das Script in der Befehlszeile überhaupt ALLE Library-Paths an den Delphi Befehlszeilen-Compiler DCC32? Das ist doch völlig unlogisch und unnötig - es soll doch nur das Indy-Package compiliert werden!

Woher soll denn MSBuild wissen, welche der Pfade Units der Indy-Bibliotheken enthalten? DAS ist unlogisch.

Um herauszufinden, welche Units benötigt werden, wird ja bereits der Compiler benötigt und ebenso der Zugriff auf die entsprechenden Units. Deshalb gibt es rein logisch keinerlei Möglichkeit, vorher herauszufinden, welche Units benötigt werden, um dann die Pfade zu filtern und dann nur die dem Compiler zu füttern, die entsprechende Units enthalten.

Davon abgesehen macht das auch keinen Sinn, denn schon dafür wird ja ebenfalls die komplette Liste der Pfade benötigt.

Delphi ist schlicht fehlerhaft eingestellt, wenn so viele Pfade im Bibliothekspfad stehen. Außerdem dauert das Kompilieren dann natürlich auch viel länger.

Zitat von PeterPanino:

Auch die Fehlermeldung "[Fatal Error] Cannot compile package 'IndySystem280' which is currently required by Delphi 11." ist unlogisch da in sich widersprüchlich.

Du musst schon vorher das in Delphi integrierte Indy entfernen, sonst klappt das nicht. Das vorhandene Package wird aktuell von Delphi verwendet, deshalb diese Meldung.

In den meisten Fällen braucht man auch gar keine neuere Version von Indy als die, die mit Delphi ohnehin schon mitgeliefert wird. Das sind nur wenige Spezialfälle.

[mjustin]

Es gibt eine recht aktuelle Anleitung dafür, wie man Indy aktualisiert:

Updating Indy

https://github.com/IndySockets/Indy/wiki/Updating-Indy

Und wenn man es einfacher haben möchte:

* die alte Indy-Version nicht deinstallieren, sondern:
* neues Indy separat installieren - einfach per Subversion svn checkout - und dann:
* nur für das Projekt die Suchpfade hinzufügen für Lib\Code, Lib\Protocols, Lib\System
* Komponenten wenn möglich nur zur Laufzeit instanziieren

So kann man
* jederzeit z.B. mit Subversion "svn update" Indy aktualisieren
* auf beliebige frühere Versionen switchen
* mehrere Indy-Versionen parallel verwenden

p.s. alternativ kann man natürlich auch dieses neue "git" verwwenden

[dummzeuch]

Abgesehen von dem, was jaenicke schon schrieb: Wenn Du neue Indy-Packages compilieren willst, solltest Du vorher die Pfade zu der mitgelieferten Indy-Version aus der IDE-Configuration entfernen, sonst werden ggf. alte Units mit neuen gemischt und man sucht sich bei Fehlern den Wolf.

[PeterPanino]

Das scheint ein allgemeines Problem bei MS Build zu sein:

Microsoft (R) Build Engine version 4.8.4084.0
[Microsoft .NET Framework, version 4.0.30319.42000]

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!

Wie kann man verhindern, dass MS Build die gesamten Library Paths (!) an dcc32 übergibt?

[PeterPanino]

Gibt es keine Möglichkeit, komfortabel ganze Gruppen von Packages zu deaktivieren? (Idealerweise auch zur Laufzeit der IDE?)

Es gibt zwar einen "Expert-Manager", mit dem man außerhalb der IDE (d.h. wenn diese nicht läuft) einzelne Packages deaktivieren/aktivieren kann:

https://github.com/DGH2112/Expert-Manager/

Aber wirklich sinnvoll wäre es nur, wenn man ganze Gruppen von Packages bequem suchen/filtern und auswählen könnte.

[PeterPanino]

Zitat von jaenicke:

Woher soll denn MSBuild wissen, welche der Pfade Units der Indy-Bibliotheken enthalten?

Ich bin kein Experte für MSBUILD, aber logischerweise müsste es doch möglich sein, nur jene Pfade zu übergeben, welche die benötigten Units enthalten. Wenn das nicht möglich ist, dann ist die Verwendung von MSBUILD zur Installation von Delphi Packages schlichtweg das falsche Werkzeug. Viele Komponenten-Hersteller verwenden für die Installation ihrer Komponenten-Packages nicht MSBUILD - und dort funktioniert es AUSGEZEICHNET!

[jaenicke]

Zitat von PeterPanino:

Ich bin kein Experte für MSBUILD, aber logischerweise müsste es doch möglich sein, nur jene Pfade zu übergeben, welche die benötigten Units enthalten.

Nein, denn der Compiler ermittelt diese ja, indem er die Units durchgeht und schaut, welche anderen Units diese wiederum benötigen. Außerdem stehen natürlich noch welche im Package.
Das hat aber nicht damit zu tun, ob MSBuild den Compiler aufruft oder Delphi selbst.

Zitat von PeterPanino:

Wenn das nicht möglich ist, dann ist die Verwendung von MSBUILD zur Installation von Delphi Packages schlichtweg das falsche Werkzeug. Viele Komponenten-Hersteller verwenden für die Installation ihrer Komponenten-Packages nicht MSBUILD - und dort funktioniert es AUSGEZEICHNET!

Das ändert nichts daran, dass die Befehlszeile trotzdem zu lang ist. Das siehst du auch in der Delphi IDE. Wenn du ein Projekt kompilierst, siehst du dort die Befehlszeile, die verwendet wird. Auch dort werden alle Pfade übergeben. Einfach weil es schlicht logisch nicht anders geht.
Das hat mit MSBuild nichts (!) zu tun. Das ist nur ein schönes Tool, damit man die dcc32.exe nicht selbst aufrufen muss.

In Delphi sieht das dann in den Meldungen z.B. so aus:

Zitat:

Der Buildvorgang wurde am 18.03.2023 15:20:35 gestartet.
__________________________________________________
Projekt F:\Embarcadero\Studio\Projekte\Project161.dproj (Build-Ziel(e)):
BuildVersionResource-Ziel:
c:\program files (x86)\embarcadero\studio\21.0\bin\cgrc.exe -c65001 Project161.vrc -foProject161.res
CodeGear Resource Compiler/Binder
Version 1.2.2 Copyright (c) 2008-2012 Embarcadero Technologies Inc.

Microsoft (R) Windows (R) Resource Compiler Version 6.0.5724.0

Copyright (C) Microsoft Corporation. All rights reserved.


Die Datei "Project161.vrc" wird gelöscht.
Die Datei "Project161.$manifest" wird gelöscht.
_PasCoreCompile-Ziel:
c:\program files (x86)\embarcadero\studio\21.0\bin\dcc32.exe -$O- -$W+ --no-config -B -Q -TX.exe -AGenerics.Collections=System.Generics.Collections; Generics.Defaults=System.Generics.Defaults;WinType s=Winapi.Windows;WinProcs=Winapi.Windows;DbiTypes= BDE;DbiProcs=BDE;DbiErrs=BDE -DDEBUG -E.\Win32\Debug -I"c:\program files (x86)\embarcadero\studio\21.0\lib\Win32\debug\DE". ..

Da folgen dann die eingetragenen Pfade.

Das Problem ist wie schon geschrieben, dass du zu viele Pfade eingetragen hast oder diese zu lang sind. Dafür kann weder Delphi noch MSBuild etwas. Du müsstest diese einfach mal aufräumen...