Einzelnen Beitrag anzeigen

Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.071 Beiträge
 
Delphi 12 Athens
 
#5

AW: Ausgabeverzeichnis für EXE und DCU nicht änderbar?

  Alt 24. Apr 2023, 01:22
Und wenn du mal z.B. auf Debug > Win32 umschaltest und dort einen Pfad einstellst? (dann natürlich auch diese Config/Platform kompilieren)

Die DPROJ könnte man auch komplett löschen.
Beim Öffnen wird dann eine neue DPROJ generiert (diese entspricht aber nicht ganz der Vorlage, für z.B. eine neue VCL-Anwendung)

Für diese beiden Verzeichnisse gibt es in Tools > Optionen keine Standardvorgabe. Aber z.B. für den BPL-Ausgabepfad dagegen schon.



Die beiden Logs Erzeugen und Ausgabe mal angesehn, was dort steht?
In Erzeugen findet sich der theoretische Aufruf für den DCC32 und da der Parameter -NO.\Win32\Debug

Oder mal auf "externen Compiler" umschalten.
Projektoptionen > Erzeugen > Delphi-Compiler > MSBuild extern ....
[edit] Hmmmmm, hier hätte ich erwartet, dass man dann im Erzeugen den Aufruf für MSBuild findet und in Ausgabe die Ausgabe des MSBuild, aber nee.

Dann eben mal manuell ... es geht ja nur darum das Ausgabelevel zu ändern. Und dafür ist es egal, ob der Befehl kopiert und um /v erweitert oder selbstgeschrieben ist.
  • im Explorer in das Verzeichnis deines Projekts
  • oben in die Adressleiste cmd reinschreiben und [ENTER]
  • dann zuerst eine Initialisierung durchführen
    "C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\rsvars.bat"
  • msbuild /v:d deinprojekt.dproj oder mit /v:diag
    bzw. in lang, siehe msbuild -h
    msbuild /verbosity:detailed /target:Rebuild /property:Config=Debug /property:Platform=Win32 deinprojekt.dproj
  • das Ergebnis etwas durchforsten, vor allem nach dem "DCC32" (wenn Win32 als Ziel eingestellt) und irgendwas mit "output"


Im Grunde ist die DPROJ ein "Script" für MSBuild, was nacheinander ausgeführt wird (ähnlich wie JavaScript, Python oder so) ... OK, nicht ganz, denn beim Inline-Compiler macht Delphi was es will, nutzt das nur als "Optionen" und geht nicht wirklich das "Script" durch, drum kann das Verhalten bei Fehlern in der DPROJ oder im Delphi sich für intern und extern unterscheiden.




Auch ist diese DPROJ nur ein Teil des ganzen Scriptes ... siehe die <IMPORT> am Ende.
Delphi-Quellcode:
    <Import Project="$(BDS)\Bin\CodeGear.Delphi.Targets" Condition="Exists('$(BDS)\Bin\CodeGear.Delphi.Targets')"/>
    <Import Project="$(APPDATA)\Embarcadero\$(BDSAPPDATABASEDIR)\$(PRODUCTVERSION)\UserTools.proj" Condition="Exists('$(APPDATA)\Embarcadero\$(BDSAPPDATABASEDIR)\$(PRODUCTVERSION)\UserTools.proj')"/>
    <Import Project="$(MSBuildProjectName).deployproj" Condition="Exists('$(MSBuildProjectName).deployproj')"/>
Ist das ein upgegradetes Projekt aus alten Delphis?
Wenn ja, denn da baut Delphi gern ein bissl Scheiße.
  • Optionen (eigentlich Variablen) in der falschen Reihenfolge oder unter falschen Namen
  • und vor allem die <Imports> falsch, da sie früher auch mal anders waren und beim Upgrade das vergessen wird
    speziell CodeGear.Delphi.Targets und darin nochmal ein/zwei importierte Freunde sind hier ganz wichtig (leider gibt es auch keine Fehlermeldung, wenn dort etwas nicht gefunden wird)
  • daher der Vorschlag die DPROJ zu löschen, weil das dann zumindestens richtig/aktuell wird
Neuste Erkenntnis:
Seit Pos einen dritten Parameter hat,
wird PoSex im Delphi viel seltener praktiziert.

Geändert von himitsu (24. Apr 2023 um 01:43 Uhr)
  Mit Zitat antworten Zitat