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:

Zitat von PeterPanino (Beitrag 1520024)

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:

Zitat von PeterPanino (Beitrag 1520024)

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:

Zitat von jaenicke (Beitrag 1520028)

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:

Zitat von PeterPanino (Beitrag 1520033)

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:

Zitat von PeterPanino (Beitrag 1520033)

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

[mjustin]

Möglicherweise ist nicht die Gesamtlänge das Problem - denn die erste Meldung ist keine Fehlermeldung sondern eine Warnung (mit Code MSB6002), die auf einen zu langen command-line String hinweist. Danach, in der Fehlermeldung mit Code MSB6003, ist nur die Rede von einem zu langen Dateinamen / einer zu langen Extension.

Wenn man im Internet zu error MSB6003 recherchiert, gelangt man schnell zu

https://learn.microsoft.com/de-de/wi...?tabs=registry

Hier wird auch beschrieben, wie man das Limit entfernen kann.

Der Fehler könnte auftreten, wenn ein einzelner der Pfade länger als 260 Zeichen ist. (z.B. ein Pfad, der eine Variable enthält).

Mittels Texteditor, in dem alle ; im Library Path durch CR/LF ersetzt werden, läßt sich das eventuell bestätigen.

[dummzeuch]

Zitat:

Zitat von PeterPanino (Beitrag 1520031)

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!

Nein, es ist kein allgemeines Problem mit MSBuild sondern es ist ein Problem mit Deiner Delphi-Installation. Der Suchpfad unter Tools -> Options ist zu lang und das betrifft dann alle Projekte, die Du zu compilieren versuchst.

Bei mir funktioniert das Compilieren der Indy-Komponenten problemlos, ebenso wie das der JCL und JVCL (die ich ebenfalls per commandline mit msbuild compiliere).

Vielleicht sind bei Dir die Pfade zu den Verzeichnissen auch extrem lang, weil Du Sourcen immer nach c:\users\<ganz langer username>\<sonstige Verzeichnisse> installierst?

Ich installiere Delphi immer nach c:\Delphi\<version> und irgendwelche Bibliotheken immer nach d:\source, so dass die Pfade relativ kurz sind, auch wenn viele Verzeichnisse drin stehen.

Zitat:

Zitat von PeterPanino (Beitrag 1520031)

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

Vorschlag: Schmeiß dort mal alles raus, was Du nicht wirklich brauchst, insbesondere die Indy-Sourcen / dcus, die mit Delphi installiert werden, dann ist der Pfad vermutlich kurz genug um keine Probleme zu bereiten.

Leider verewigen sich dort auch diverse Bibliotheken, wobei das wohl auch die Empfehlung seitens Embarcadero ist. Das heißt aber dann auch, dass die immer verwendet werden, egal ob man die Bibliothek in einem Projekt verwendet oder nicht.

[PeterPanino]

Zitat:

Zitat von jaenicke (Beitrag 1520034)

Das ändert nichts daran, dass die Befehlszeile trotzdem zu lang ist.

Sie ist wegen des NACHTEILS von MSBUILD zu lang, ausnahmslos alle Library Paths an dcc32 zu übergeben. Wegen dieses (möglicherweise nicht zu umgehenden Nachteils) ist wie ich bereits sagte, MSBUILD das FALSCHE WERKZEUG für die Installation von Delphi Packages. Es ist nicht ersichtlich, wieso manche Komponenten-Hersteller trotz dieser erwiesenen Nachteile trotzdem MS-BUILD einsetzen. Ist es Bequemlichkeit, weil sie einfach den Build-Prozess aus ihrer eigenen Komponenten-Kompilierung übernehmen? Ist es Unwissenheit?

[PeterPanino]

Zitat:

Zitat von dummzeuch (Beitrag 1520036)

Schmeiß dort mal alles raus, was Du nicht wirklich brauchst

Ist es Überheblichkeit, mit der zu wissen glaubst, was ich brauche oder nicht?

Außerdem scheinst du noch immer nicht zur Kenntnis genommen zu haben, dass MSBUILD der tatsächliche Urheber für den Fehler ist.

[jaenicke]

Zitat:

Zitat von PeterPanino (Beitrag 1520037)

Sie ist wegen des NACHTEILS von MSBUILD zu lang, ausnahmslos alle Library Paths an dcc32 zu übergeben. Wegen dieses (möglicherweise nicht zu umgehenden Nachteils) ist wie ich bereits sagte, MSBUILD das FALSCHE WERKZEUG für die Installation von Delphi Packages.

Du hast offensichtlich nicht verstanden was ich geschrieben habe. Das hat nichts mit MSBuild zu tun. Rein gar nichts. Deshalb mal hier ein Screenshot...

Anhang 55907

Auch beim Aufruf aus der IDE heraus muss der Compiler die Pfadangaben bekommen. Wie sollte das denn sonst auch gehen?

Stell dir mal vor, dass du jemandem sagst, dass er alle Personen mit dem Nachnamen Müller aus dem Telefonbuch heraussuchen soll, aber das Telefonbuch zum Nachschlagen bekommt er nicht. Das kann nicht klappen...
Wie soll der Compiler die Units denn finden, wenn er nicht gesagt bekommt, wo diese liegen können?

Und wenn in der Konfiguration ein Fehler ist (zu langer einzelner Pfad oder zu viele Pfade insgesamt), dann funktioniert es eben nicht.

[PeterPanino]

[QUOTE=jaenicke;1520039]

Zitat:

Zitat von PeterPanino (Beitrag 1520037)

Auch beim Aufruf aus der IDE heraus muss der Compiler die Pfadangaben bekommen.

Aber er übergibt nicht alle Library-Pfade auf einmal an eine Befehlszeile mit begrenztem Fassungsvermögen, sondern sieht selbst in den Library-Pfaden nach. Nimm das bitte endlich mal zur Kenntnis.

[dummzeuch]

OK, wir sind bei Beleidigungen und Großchrift angekommen. Ich bin dann raus.

[jaenicke]

Zitat:

Zitat von PeterPanino (Beitrag 1520040)

Aber er übergibt nicht alle Library-Pfade auf einmal an eine Befehlszeile mit begrenztem Fassungsvermögen, sondern sieht selbst in den Library-Pfaden nach. Nimm das bitte endlich mal zur Kenntnis.

Das stimmt schlicht nicht und das lässt sich ja schon in dem eben gezeigten Screenshot ganz leicht erkennen. Es handelt sich um ein leeres neues Projekt. Wenn deine Annahme richtig wäre, wären da z.B. schon die JCL- und JVCL-Pfade nicht drin. (Ja, wie ich gerade sehe, konnte man es schlecht erkennen, da das Forum leider schlecht komprimiert. Ich habe den Screenshot eben ausgetauscht, inhaltlich ist er identisch, nur mit niedriger Auflösung gemacht.)

Jedenfalls habe ich durchaus zur Kenntnis genommen, dass du irgendwo eine Magie vermutest, die vorher herausfindet, welche Pfade gebraucht werden. Aber weder existiert diese noch wäre diese logisch möglich, ohne dafür Compilerfunktionen zu nutzen (z.B. im Rahmen des LSP-Hintergrundcompilers). Denn ohne Compilerfunktionen ist es nun einmal unmöglich zu wissen, welche Units benötigt werden, und dementsprechend welche Pfade nötige Units enthalten.

[PeterPanino]

[QUOTE=jaenicke;1520044]

Zitat:

Zitat von PeterPanino (Beitrag 1520040)

Jedenfalls habe ich durchaus zur Kenntnis genommen, dass du irgendwo eine Magie vermutest

Ist die Glaskugel, mit der du deine Erkenntnis gewinnst, auch von Microsoft?

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;

oder vielleicht noch besser:

Delphi-Quellcode:

if LibraryPaths.Count > X then
begin
  if CompilationByMSBUILD then
    Result := Error
  else if CompilationByDCC32 then
    Result := OK;
end;

[jaenicke]

Der Unterschied ist, dass MSBuild die Validität prüft und ggf. Fehler meldet, während der Aufruf aus der IDE ohne diese Prüfungen gemacht wird. Wenn du nun bemängelst, dass MSBuild eine fehlerhafte Konfiguration nicht einfach so übergeht (und dich ggf. später in Fehler laufen lässt, mit denen du nichts anfangen kannst), kannst du das natürlich tun. Das ändert aber nichts daran, dass der Fehler nicht bei MSBuild liegt.

Zudem hilft es dir auch nicht weiter. Deshalb verstehe ich nicht, weshalb du dich darüber aufregst, statt einfach deine Konfiguration zu korrigieren...

In früheren Versionen von Delphi führte ein zu langer Biblitohekspfad übrigens dazu, dass die Kommandozeile für die dcc32.exe irgendwann abgeschnitten wurde, was zu teilweise recht seltsamen Fehlermeldungen führte. Ich hoffe, dass das mittlerweile abgefangen wird, aber ausprobiert habe ich das nicht. Zu lange einzelne Pfade hingegen wurden ggf. einfach ignoriert, so dass man sich nur gewundert hat, warum die Units nicht gefunden werden (was eben bei MSBuild geprüft und dir gemeldet wird).

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

[dummzeuch]

Zitat:

Zitat von jaenicke (Beitrag 1520058)

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. :thumb:

[Delphi.Narium]

Zitat:

Zitat von PeterPanino (Beitrag 1520057)

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.

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:

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.

[PeterPanino]

Zitat:

Zitat von jaenicke (Beitrag 1520058)

Nichts anderes habe ich geschrieben.

NEIN. Auch das ist falsch. Du hast geschrieben:

Zitat:

Zitat von jaenicke (Beitrag 1520056)

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:

Zitat von PeterPanino (Beitrag 1520061)

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.

Anhang 55909

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.

[blawen]

Zitat:

Zitat von PeterPanino (Beitrag 1520031)

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:

Zitat von blawen (Beitrag 1520065)

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.

[PeterPanino]

Zitat:

Zitat von jaenicke (Beitrag 1520063)

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:

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:

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:

Zitat von Delphi.Narium (Beitrag 1520072)

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:

Anhang 55913

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?