Indy-Installation funktioniert nicht

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

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 von PeterPanino:

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 von jaenicke:

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 von dummzeuch:

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 von PeterPanino:

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



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 von PeterPanino:

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 von PeterPanino:

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 von PeterPanino:

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