![]() |
AW: Indy-Installation funktioniert nicht
Zitat:
|
AW: Indy-Installation funktioniert nicht
Zitat:
Wenn die IDE oder MSBuild den Kompiler aufrufen, werden aber noch weitere Verzeichnisse übergeben, möglich wären da u. a.:
Code:
Ebenso werden auf der Kommandozeile sämtliche in der IDE konfigurierten Kompileroptionen übergeben.
OutputDir
UnitOutputDir PackageDLLOutputDir PackageDCPOutputDir SearchPath Packages 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:
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:
Letztlich entspricht Dein Aufruf "nur"
Syntax: dcc32 [optionen] dateiname [optionen]
Code:
und damit kann der Fehler, der durch zuviele Informationen in den Optionen hervorgerufen wird, nicht auftreten, da sie ja nicht angegeben wurden.
Syntax: dcc32 dateiname
|
AW: Indy-Installation funktioniert nicht
Zitat:
Zitat:
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. |
AW: Indy-Installation funktioniert nicht
Liste der Anhänge anzeigen (Anzahl: 2)
Zitat:
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. |
AW: Indy-Installation funktioniert nicht
Zitat:
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. ![]() ![]() Seitdem ich den Pfad massiv eingekürzt habe, z.B. C:\T\FNC\UI, habe ich diesbezüglich keine Probleme mehr. |
AW: Indy-Installation funktioniert nicht
Zitat:
Ü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. |
AW: Indy-Installation funktioniert nicht
Zitat:
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." |
AW: Indy-Installation funktioniert nicht
Zitat:
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:
Zeig' uns doch bitte mal den Kommandozeilenaufruf von DCC32.exe für das Projekt, bei dem der o. g. Fehler auftrat,
Code:
enthält jedenfalls keine Unitangaben in der Kommandozeile, sondern nur den Namen des zu kompilierenden Projektes.
"C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\DCC32.EXE" "C:\DELPHI\Mein Test\Test.dpr"
|
AW: Indy-Installation funktioniert nicht
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:
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. |
AW: Indy-Installation funktioniert nicht
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? |
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:49 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz