Pascal Project Manager & Editor

[Harry Stahl]

OK, vielen Dank Euch beiden für die hilfreichen Hinweise.

Ich bastele gerade ein wenig daran rum, siehe anliegenden Screenshot.

Habe also den Aufruf des Kompilierungsvorgangs in einen eigenen Dialog gelegt, wo man bestimmte Auswahlen treffen kann.

DCC funktioniert wie bisher. Für MSBuild funktioniert bereits die einfache Wahl Release oder Debug. Wie wähle ich hier, ob ein 32-Bit oder 64-Bit Kompilat erzeugt wird?

Und wie, für welche Plattform (Windows, MAC, usw) erzeugt werden soll?

Außerdem werden anscheinend alle Plattformen mit diesem Aufruf erzeugt, oder?

Wenn man den DCC-Compiler verwendet und man dort die Suchpfade angeben will (ist Das der "-I" oder "-U" Parameter?) kann der dann selber solche Angaben auflösen wie:

$(crossvcl)\Lib\$(ProductVersion)\$(Platform)\$(Co nfig)

?

Wo schreibt der DCC-Compiler eigentlich die erzeugten DCU-Units hin, ich kann die hier im Moment gar nicht finden?

[jziersch]

-E<path> = Ausgabeverzeichnis für EXE
-N<path> = DCU-Ausgabeverzeichnis
-O<paths> = Objektverzeichnisse

Hier die Optionen für Delphi 7:

Code:

Syntax: dcc32 [optionen] dateiname [optionen]

  -A<unit>=<alias> = Unit-Alias setzen   -LU<package> = Package verwenden
  -B = Alle Units erzeugen               -M = Modifizierte Units erzeugen
  -CC = Ziel: Konsole                    -N<path> = DCU-Ausgabeverzeichnis
  -CG = Ziel: GUI                        -O<paths> = Objektverzeichnisse
  -D<syms> = Bedingungen definieren      -P = Auch nach 8.3-Dateinamen suchen
  -E<path> = Ausgabeverzeichnis für EXE  -Q = Ohne Meldung compilieren (Quiet)
  -F<offset> = Suchfehler                -R<paths> = Ressourcenverzeichnisse
  -GD = Detaillierte Map-Datei           -U<paths> = Unit-Verzeichnisse
  -GP = Map-Datei mit publics            -V = Debug-Information in EXE
  -GS = Map-Datei mit Segmenten          -VR = Externe Fehlersuche gen.
  -H = Ausgabe von Hinweismeldungen      -W = Ausgabe von Warnungen
  -I<paths> = Include-Verzeichnisse      -Z = Ausgabe nie zu erstellender DCPs
  -J = .obj-Dateien generieren           -$<dir> = Compiler-Direktive
  -JP = C++-.obj-Datei generieren       --help = Diesen Hilfebildschirm anzeigen
  -K<addr> = Image-Basisadresse          --version = Name und Version anzeigen
Compiler-Schalter: $<buchst><status> (Vorgabewerte siehe unten)
  A8  Ausgerichtete Record-Felder         P+  Offene String-Parameter
  B-  Vollst.  boolesche Auswertung       Q-  Integer-Überlaufprüfung
  C+  Zur Laufzeit Bedingungen auswerten  R-  Bereichsüberprüfung
  D+  Debug-Information                   T-  Typisierter @-Operator
  G+  Importierte Datenreferenzen verw.   U-  Pentium(tm)-sichere Division
  H+  Standardmäßig lange Strings verw.   V+  Strenge Prüfung von var-Strings
  I+  Ein-/Ausgabeprüfung                 W-  Stack-Frames erzeugen
  J-  Strukt. Consts (Schreibzugriff)     X+  Erweiterte Syntax
  L+  Lokale Debug-Symbole                Y+  Symbolinformation
  M-  Laufzeit-Typinfo (RTTI)             Z1  Mindestgröße für Enum-Typen
  O+  Optimierung

Für Delphi 10.3 - 64 bit

Code:

Syntax: dcc64 [Optionen] Dateiname [Optionen]

  -A<unit>=<alias> = Unit-Alias setzen
  -B = Alle Units erzeugen
  -CC = Ziel: Konsole
  -CG = Ziel: GUI
  -D<syms> = Bedingungen definieren
  -E<path> = EXE/DLL-Ausgabeverzeichnis
  -F<offset> = Fehlersuche
  -GD = Detaillierte Map-Datei
  -GP = Map-Datei mit publics
  -GS = Map-Datei mit Segmenten
  -H = Ausgabe von Hinweismeldungen
  -I<paths> = Include-Verzeichnisse
  -J = .obj-Dateien generieren
  -JPHNE = C++ .obj-Datei, .hpp-Datei, im Namespace erzeugen, alles exportieren
  -JL = Package-.lib, -.bpi und alle .hpp-Dateien für C++ erzeugen
  -K<addr> = Image-Basisadresse
  -LE<path> = Package .bpl-Ausgabeverzeichnis
  -LN<path> = Package .dcp-Ausgabeverzeichnis
  -LU<package> = Package verwenden
  -M = Modifizierte Units erzeugen
  -NU<Pfad> = Unit-DCU-Ausgabeverzeichnis
  -NH<path> = Unit .hpp-Ausgabeverzeichnis
  -NO<path> = Unit .obj-Ausgabeverzeichnis
  -NB<path> = Unit .bpi-Ausgabeverzeichnis
  -NX<Pfad> = Unit-XML-Ausgabeverzeichnis
  -NS<namespaces> = Namespace-Suchpfad
  -O<paths> = Objektverzeichnisse
  -P = Auch nach 8.3-Dateinamen suchen
  -Q = Ohne Meldung compilieren (Quiet)
  -R<paths> = Ressourcenverzeichnisse
  -TX<Erw.> = Erweiterung des Ausgabenamens
  -U<paths> = Unit-Verzeichnisse
  -V = Debug-Information in EXE
  -VR = Externe Fehlersuche gen.
  -VT = Debug-Informationen in TDS
  -VN = TDS-Symbole im Namespace
  -W[+|-|^][warn_id] = Ausgabe von Warnmeldungen
  -Z = Ausgabe nie zu erstellender DCPs
  -$<dir> = Compiler-Direktive
  --help = Diesen Hilfebildschirm anzeigen
  --version = Name und Version anzeigen
  --codepage:<cp> = Codierung für Quelltextdatei festlegen
  --default-namespace:<namespace> = Namespace setzen
  --depends = Unit-Abhängigkeitsinformationen ausgeben
  --doc = XML-Ausgabedokumentation
  --drc = Ausgabe-Ressourcenstring .drc-Datei
  --no-config = Standard-dcc64.cfg-Datei nicht laden
  --description:<String> = Beschreibung für ausführbare Datei festlegen
  --inline:{on|off|auto} = Inlining von Funktionen steuern
  --legacy-ifend = Alte $IFEND-Direktive zulassen
  --zero-based-strings[+|-] = Indizierung der Strings beginnt mit 0
  --peflags:<Flags> = Zusätzliches Flags-Feld für PE-Header setzen
  --peoptflags:<Flags> = Zusätzliches Feld für optionale Flags für PE-Header setzen
  --peosversion:<Haupt>.<Neben> = BS-Versionsfelder in PE-Header setzen (Vorgabe: 5.0)
  --pesubsysversion:<Haupt>.<Neben> = Untersystem-Versionsfelder in PE-Header setzen (Vorgabe: 5.0)
  --peuserversion:<Haupt>.<Neben> = Benutzer-Versionsfelder in PE-Header setzen (Vorgabe: 0.0)
  --lib-version:<Version> = Version des Ausgabe-Package-Namens
  --lib-suffix:<Suffix> = Suffix des Ausgabe-Package-Namens

Je nach Platform gibt es ja verschiedene compiler, also auch OSX...

Ich halte es für wichtig wahlweise den compiler direkt anzusprechen (und nicht MSBuild), da man dadurch Projekt unabhängig kompilieren kann. Also alles was man im Projekt (*.dproj) oder den Pfaden evtl. verstellt hat spielt keine Rolle, und man erhält wirklich das Ergebnis so, wie es im Projekt Manager hinterlegt ist. Auch funktioniert DCxx sehr zuverlässig.

[dummzeuch]

Zitat von Harry Stahl:

Für MSBuild funktioniert bereits die einfache Wahl Release oder Debug. Wie wähle ich hier, ob ein 32-Bit oder 64-Bit Kompilat erzeugt wird?

Und wie, für welche Plattform (Windows, MAC, usw) erzeugt werden soll?

Du kannst Dir von der IDE den Aufruf für's compilieren anzeigen lassen. Ich weiß nur gerade nicht mehr, wo man das einstellt.

twm

[ringli]

Zitat von Harry Stahl:

Für MSBuild funktioniert bereits die einfache Wahl Release oder Debug. Wie wähle ich hier, ob ein 32-Bit oder 64-Bit Kompilat erzeugt wird?

Ich hoffe das beantwortet deine Frage:

Code:

msbuild.exe "Project.dproj" /target:Clean;Build /p:Platform=Win32 /p:config=Release
msbuild.exe "Project.dproj" /target:Clean;Build /p:Platform=Win64 /p:config=Release

[jziersch]

@Harry

Grossartig, es läuft viel weiter. Jetzt kommen auch lesbare Fehlermeldungen.

Mein grosses FMX Projekt konnte msbuild kompilieren und es wurde die Ausgabe Datei erstellt. Allerdings zeigt sich der Naschteil hier, da eben die Einstellungen des Projektes komplett verwendet werden und die EXE in dem dort eingestellten Verzeichnis erstellt wird. Das ist zwar oft gewünscht, aber nicht immer, gerade bei einem Projekt welches man schon ewig nicht mehr angefasst hat. Mir geht es darum ein Projekt so in PPM zu erfassen, dass es immer kompilierbar ist, mit den gespeicherten Pfaden etc, unabhängig von der IDE die evtl. bereits andere Komponenten verwendet. Es sieht so aus, als ob genau das kommt. Toll!

DCC, was mich daher insbesondere interessier lief auch ganz gut. Besonders zeigt sich dass hier alle units gelistet werden. Es ist die method um die Abhängigkeiten zu finden. Könnten die direkt so in das Projekt in PPM eingetragen werden? Ganz wichtig ist die DCC Pfade auch im Projekt abzuspeichern, also für später.

In meinem Fall kommt:

C:\....\unitname.pas(42) Schwerwiegend: F2613 Unit 'SysUtils' nicht gefunden.

Das problem war ein fehlender namespace. Keine grosse Sache.

Ich habe auch ein paar Symbole mit -D... als parameter hinzugefügt. Funktioniert insgesamt sehr gut.

Kannst Du bitte vielleicht einen Knopf auf deinem neuen Formular anbringen "Parameter in Projekt merken", sodass die Einstellungen, parameter und(!) Pfade genau wie verwendet für den nächsten Aufruf gespeichert werden. Dann wäre es perfekt, denke ich.

[Harry Stahl]

Zitat von jziersch:

@Harry

Grossartig, es läuft viel weiter. Jetzt kommen auch lesbare Fehlermeldungen.

Mein grosses FMX Projekt konnte msbuild kompilieren und es wurde die Ausgabe Datei erstellt. Allerdings zeigt sich der Naschteil hier, da eben die Einstellungen des Projektes komplett verwendet werden und die EXE in dem dort eingestellten Verzeichnis erstellt wird. Das ist zwar oft gewünscht, aber nicht immer, gerade bei einem Projekt welches man schon ewig nicht mehr angefasst hat. Mir geht es darum ein Projekt so in PPM zu erfassen, dass es immer kompilierbar ist, mit den gespeicherten Pfaden etc, unabhängig von der IDE die evtl. bereits andere Komponenten verwendet. Es sieht so aus, als ob genau das kommt. Toll!

DCC, was mich daher insbesondere interessier lief auch ganz gut. Besonders zeigt sich dass hier alle units gelistet werden. Es ist die method um die Abhängigkeiten zu finden. Könnten die direkt so in das Projekt in PPM eingetragen werden? Ganz wichtig ist die DCC Pfade auch im Projekt abzuspeichern, also für später.

In meinem Fall kommt:

C:\....\unitname.pas(42) Schwerwiegend: F2613 Unit 'SysUtils' nicht gefunden.

Das problem war ein fehlender namespace. Keine grosse Sache.

Ich habe auch ein paar Symbole mit -D... als parameter hinzugefügt. Funktioniert insgesamt sehr gut.

Kannst Du bitte vielleicht einen Knopf auf deinem neuen Formular anbringen "Parameter in Projekt merken", sodass die Einstellungen, parameter und(!) Pfade genau wie verwendet für den nächsten Aufruf gespeichert werden. Dann wäre es perfekt, denke ich.

Habe die aktualisierte Version gerade hochgeladen, Dialog sieht nun so aus, wie in der Anlage. Pro Projekt wird nun eine Datei mit dem Namen der Projekt-Datei, aber Dateiendung '.pecs" (für PascalEditorCompilerSettings) in das Projektverzeichnis gespeichert.

In dieser Datei werden dann die Einstellungen für den Dialog gespeichert, man kann derzeit bis zu 25 unterschiedliche Compiler-Settings pro Projekt anlegen (kann ich erhöhen, falls das nicht reichen sollte).

Programm merkt sich auch die zuletzt verwendeten Settings und stellt diese dann wieder her, wenn man den Dialog erneut aufruft (ist ganz praktisch, wenn man mit den DCC-Paramentern ein wenig herumspielt).

Bezüglich MSBuild: Da lese ich nun aus der rsvars.bat das richtige Framework aus (ab Delphi 10.3 ja wohl Framework 4), so dass der entsprechende MSBuild-Compiler verwendet wird.

[jziersch]

Hallo Harry,

Hier noch etwas feedback zu aktuellen 3.23

1) Ich falle immer darauf ein, dass ein Doppelklick die IDE startet. Kann man das so konfigurieren, dass sich der PPME öffnet?

2) Die Kompilation mit msbuild ist erfolgreich. Allerdings wird die ausführbare Datei bei mir ganz woanders erstellt, eben wie im Projekt angegeben. Dort wird sie aber von PPME nicht gefunden.

3) Die Logik der Parameter Speicherung scheint mir nicht nicht ganz perfekt zu sein. Bei einem erneuten Öffnen von PPME sind die Einträge nicht mehr da.

4) Ein msbuild Lauf erzeugt bei mir


Compiling:
S:\MyProjects\....dproj

...

_PasCoreCompile:
C:\Delphi\DX13\bin\dcc64.exe -$D0 -$L- -$Y- --no-config ... MeinProjekt.dpr

Diese Zeile nach "_PasCoreCompile" beinhaltet alle Parameter und Suchpfade für eine direkte Ausführung des Dxx compilers. PME könnte diese Zeile auswerten und in die Konfiguration des Projektes aufnehmen. Damit kann DCC zu einem späteren Zeitraum direkt ausgeführt werden. Ich habe dies in einer BAT Datei gemacht, und es wurde anstandslos ein Projekt erzeugt.

Interessant wäre die Auswertung der Parameter
-ED:\xxxx AUSGABEVERZEICHNIS
-Ic:\Delphi\dx13\lib\Win64\re SUCHPFAD
-Rc:\Delphi\dx13\li Weiterer Suchpfad
-Uc:\Delphi\ Weiterer Suchpfad
-NU.\Win64\Release Die Units
-NSWinapi;System.Win;Data.Win;Datasnap Die namespaces

Ich habe probiert diese Werte manuell für den Aufruf von DCC einzutragen, nur leider hat das nicht geklappt, da es immer einen 32/64 bit Versionsfehler gab. Prinzipiell müsste es aber gehen, die BAT Datei funktioniert ja.

Wieso sich der Aufwand mit DCC lohnt:

1) Über DCC (und andere Dxxx) kann man ein Projekt immer kompilieren, sofern man die Parameter
archiviert hat, unabhängig von der aktuellen Konfiguration. Also auch nach Jahren, wenn man nur die Pfade nicht geändert hat.

2) Es lässt sich über --doc -NXpfad für jede source unit eine XML Datei generieren, dies kann helfen alle eingebundenen units zu finden. Die Haupt XML Datei des Projektes enthält alle eingebunden namespaces / units:

Code:

<namespace name="MeinProject" platform="Win64">
  <contains name="FMX.Filter.Effects" />
  <contains name="FMX.Filter.Standard" />
  <contains name="FMX.ComboTrackBar" />
  <contains name="FMX.ComboTrackBar.Style" />

was sich dazu anbietet, von PME ausgewertet zu werden.

Viele Grüsse,
Julian

[Harry Stahl]

Zitat von jziersch:

Hallo Harry,

Hier noch etwas feedback zu aktuellen 3.23

1) Ich falle immer darauf ein, dass ein Doppelklick die IDE startet. Kann man das so konfigurieren, dass sich der PPME öffnet?

Ich habe in der aktuellen Version 3.26 jetzt unter Extras, Optionen, Programmverhalten eine Option eingebaut, dass man wählen kann, was sich per Doppelklick öffnet (IDE oder Pascal Editor).

Hinweis: Dumzeuch hatte sich mal einen Modifier für das Starten per Returntaste gewünscht (gehaltene Shift-Taste öffnete dann den Pascal-Editor, statt IDE), was ich auch eingebaut hatte.

Wenn man nun den Doppelklick auf das Projekt als Standard so umstellt, dass sich der Pascal-Editor öffnet, hat Return+Shift-Taste nun den umgekehrten Effekt, öffnet dann also die IDE.

Zitat von jziersch:

2) Die Kompilation mit msbuild ist erfolgreich. Allerdings wird die ausführbare Datei bei mir ganz woanders erstellt, eben wie im Projekt angegeben. Dort wird sie aber von PPME nicht gefunden.

Hatte ich schon in Version 3.25 verbessert, dass aus dem Projekt der Exe-Ausgabepfad ausgelesen wird und PE daher dort das Programm startet.

Zitat von jziersch:

3) Die Logik der Parameter Speicherung scheint mir nicht nicht ganz perfekt zu sein. Bei einem erneuten Öffnen von PPME sind die Einträge nicht mehr da.

Die Einstellungen werden für jedes Projekt separat gespeichert (Projekt-Dateiname, Endung durch '.pecs' ersetzt). Wenn Du also ein anderes Projekt öffnest, gibt es dort erst mal keine Einträge.

Die anderen von Dir erwähnten Dinge sehe ich mir an und prüfe, was ich machen kann.

Die nächsten Dinge die auf dem Plan stehen, sind Direkt-Zip der Projekt-Dateien bzw. eine Dokumentationsfunktion (angelehnt an Documentation insight).

[Harry Stahl]

Ich bin gerade dabei, die schon mal vor einiger Zeit angekündigte Dokumentations-Funktion einzubauen.

Dazu habe ich erst mal eine Möglichkeit geschaffen, die Parameter, die Delphi selber als XML-Dokumentations-Tags anbietet, wenn man Strg+J drückt, mit Hilfe eines kleinen Dialog-Fensters sehr viel einfacher eingeben oder ändern zu können, siehe anliegenden Screenshot.

XML-Parameter gibt es aber auch weitere, daher wollte ich mal hier die Frage stellen, ob man zusätzliche Parameter hier anbieten sollte (vgl: https://docs.microsoft.com/de-de/dot.../codedoc#param) oder reicht es im Prinzip so?

Weiterhin: Ich überlege, ob ich kurze Einträge statt mehrzeilig, einzeilig erfassen soll,

also statt:

/// <summary>
/// Looks for a special Message
/// </summary>

lieber so:

/// <summary>Looks for a special Message</summary>

Gibt es irgendwelche Tools, die damit nicht zurecht kommen oder andere Gründe diese 2. Variante nicht zu wählen? Immerhin nimmt diese nur eine Zeile weg.
Bei 3 unterschiedlichen XML-Tags mit kurzen Einträgen hätte man nur 3 statt 9 Zeilen...

Hinweis: Diese Funktion ist noch nicht in der Version auf meiner HP enthalten...