Indy-Installation funktioniert nicht

[dummzeuch]

Zitat von jaenicke:

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.

[Delphi.Narium]

Zitat von PeterPanino:

Zitat von jaenicke:

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

Nichts anderes habe ich geschrieben.

NEIN. Auch das ist falsch. 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 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 von PeterPanino:

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.



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

[PeterPanino]

Zitat von jaenicke:

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



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?