Delphi 2009 Projekt im Batch kompilieren (OHNE IDE!)

[kaju74]

Hallo.

Ich stehe hier vor dem Problem, etwa 60 Delphi2009-Projekte neu kompilieren zu müssen, wenn ich etwas geändert habe und von ALLEN Projekten eine aktuelle EXE benötige (z.B. Änderung der Resourceinformationen).

Das Ganze sollte möglichst nicht innerhalb der IDE ablaufen sondern über ein externen Tool. Wir habe hier zwar FinalBuilder5 im Einsatz, aber eben diese 5-er Version unterstützt noch keinen D2009-Compiler.

Hier geht's auch wirklich nur darum, die .dpr-Dateien neu zu kompilieren, mit allen Such- und Bibiliothekspfaden, usw. Bei dem Kommandozeilen-Compiler scheieters bei mir immer daran, das er die Umgebung nicht finden (Pfade, ...).

Gibt's irgendein nettes Tool (möglichst Freeware , um so eine Batch-Kompilierung durchzuführen?

Vielen Dank & Gruß,
kaju

[mjustin]

Zitat von kaju74:

Hallo.

Ich stehe hier vor dem Problem, etwa 60 Delphi2009-Projekte neu kompilieren zu müssen, wenn ich etwas geändert habe und von ALLEN Projekten eine aktuelle EXE benötige (z.B. Änderung der Resourceinformationen).

Das Ganze sollte möglichst nicht innerhalb der IDE ablaufen sondern über ein externen Tool. Wir habe hier zwar FinalBuilder5 im Einsatz, aber eben diese 5-er Version unterstützt noch keinen D2009-Compiler.

Hier geht's auch wirklich nur darum, die .dpr-Dateien neu zu kompilieren, mit allen Such- und Bibiliothekspfaden, usw. Bei dem Kommandozeilen-Compiler scheieters bei mir immer daran, das er die Umgebung nicht finden (Pfade, ...).

Gibt's irgendein nettes Tool (möglichst Freeware , um so eine Batch-Kompilierung durchzuführen?

Vielen Dank & Gruß,
kaju

Seit einigen Jahren setze ich Apache Ant dafür ein (in vielen Projekten auch mit großer Zahl Projektdateien). In älteren Forumsbeiträgen habe ich weitere Details zu Ant geschrieben. Es gibt auch eine Version für .Net, die kein Java erfordert - und ebenfalls als moderner Make-Ersatz taugt.

Viele Grüße,

[MaBuSE]

Zitat von kaju74:

... Das Ganze sollte möglichst nicht innerhalb der IDE ablaufen sondern über ein externen Tool. ... Hier geht's auch wirklich nur darum, die .dpr-Dateien neu zu kompilieren, mit allen Such- und Bibiliothekspfaden, usw. Bei dem Kommandozeilen-Compiler scheieters bei mir immer daran, das er die Umgebung nicht finden (Pfade, ...).
Gibt's irgendein nettes Tool (möglichst Freeware , um so eine Batch-Kompilierung durchzuführen?

Das ist relativ einfach

• Kommandozeile öffnen (cmd.exe)
• rsvars.bat aufrufen (solte im Pfad sein $(BDS)\bin )
• cd Projektverzeichnis
• msbuild Projektname.dproj
  -> Alternativ kann der Parameter /p:Configuration=Debug bzw Release angegeben werden
  -> Alternativ kann auch ein Target angegeben werden /t:Build oder /t:Make oder /t:Clear
  
  z.B.
  cd /d C:\temp\Demo1
  msbuild Project1.dproj /p:Configuration=Debug /t:Build

Das jeweils für jedes Projekt

oder

• Projektgruppe in IDE erzeugen mit allen Projekten
  -> Mann kann auch Abhänigkeiten einstellen (Reihenfolge beim Build)
• Kommandozeile
• cd "Verzeichnis der Gruppendatei"
• rsvars aufrufen
• msbuild myGroup.groupproj /p:Configuration=Release /t:BuildAll
  -> Es werden alle Projekte erzeugt. Und zwar mit den jeweiligen Projekteinstellungen.

Das geht (glaube ich) ab Delphi 2006
(Wir verwenden das unter D2007 for Win32)

Ich hoffe das hilft Dir.

[kaju74]

Cool...genau sowas hatte ich mir vorgestellt )

Probiere ich gleich mal aus...vielen Dank...

Kurze Frage am Rande:

Zitat:

msbuild myGroup.groupproj /p:Configuration=Release /t:BuildAll

Hier sehe ich, das mit dem Parameter "/p:Configuration=Release" bestimmt werden kann, ob das Projekt als "Debug" oder
"Release" gebuildet werden kann. Sowas wollte ich auch in einem Verbund aus TeamCity und MSBuild machen, weiß aber bisher
nicht, wo ich das eintragen kann/soll. Das Ganze läuft auf einer VM (BuildServer)...lokal hatte ich mit msbuild noch nichts
gemacht, sonst wäre mir diese Idee vielleicht vonselber gekommen

Nochmals Danke,
kaju

[MaBuSE]

Zitat von kaju74:

Hier sehe ich, das mit dem Parameter "/p:Configuration=Release" bestimmt werden kann, ob das Projekt als "Debug" oder "Release" gebuildet werden kann. Sowas wollte ich auch in einem Verbund aus TeamCity und MSBuild machen, weiß aber bisher nicht, wo ich das eintragen kann/soll. Das Ganze läuft auf einer VM (BuildServer)...lokal hatte ich mit msbuild noch nichts gemacht, sonst wäre mir diese Idee vielleicht vonselber gekommen

Wir haben auf unserem BuildServer mit der Verwendung von msbuild die Unterschiede zu VisualStudio und Delphi deutlich reduzieren können.

Die einzelnen Properties und Targets sind in den *.dproj und *.targets Dateien definiert.
Letztere werden von den *.dproj Dateien referenziert.

JclPackagesD110.groupproj (Beispiel JEDI JCL Projekt)

...
<Target Name="Build">
<CallTarget Targets="Jcl;JclVcl;JclContainers;JclBaseExpert;Jc lDebugExpert;JclFavoriteFoldersExpert;
JclProjectAnalysisExpert;JclRepositoryExpert;JclSI MDViewExpert;JclStackTraceViewerExpert;JclVersionC ontrolExpert" />
</Target>
...

oder

Jcl.dproj (Beispiel JEDI JCL Projekt)

...
<Configuration Condition=" '$(Configuration)' == '' ">Release</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
...
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
...
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
...
<Import Project="$(MSBuildBinPath)\Borland.Delphi.Targets" />
...

oder

Borland.Delphi.Targets (gehört z.B. zu Delphi 2007)

...
<Target Name="default" DependsOnTargets="Make"/>
...

Wie man erkennen kann, sind die default Optionen: /t:Make /p:Configuration=Release /platform=AnyCPU
Du kannst im Delphi ja eigene Gruppen definieren und ansteuern. Da in den Gruppen auf DEFINES, Directories, ... gesetzt werden können, wäre auch so was wie

Code:

msbuild SuperProjekt.dproj /t:build /p:Configuration=Kunde1
msbuild SuperProjekt.dproj /t:build /p:Configuration=Kunde2
msbuild SuperProjekt.dproj /t:build /p:Configuration=Kunde3

denkbar.
Via Define werden dann z.B. Kundenspezifische Änderungen kompiliert.
Nach dem Build Liegen dann z.B. in D:\SuperProjekt\Release\Kunde1, D:\SuperProjekt\Release\Kunde2, D:\SuperProjekt\Release\Kunde3 die ausführbaren Dateien.


ruf mal msbuild mit dem Parameter /help auf

Code:

M:\d11_test\shared\Baselines\JEDI\JCL\Delphi11\Source\packages>msbuild /help

Microsoft (R)-Buildmodul, Version 2.0.50727.3053
[Microsoft .NET Framework, Version 2.0.50727.3082]
Copyright (C) Microsoft Corporation 2005. Alle Rechte vorbehalten.

Syntax:              MSBuild.exe [Optionen] [Projektdatei]

Beschreibung:        Erstellt die in der Projektdatei angegebenen Ziele.
                     Wenn keine Projektdatei angegeben ist, durchsucht MSBuild
                     das aktuelle Arbeitsverzeichnis nach einer Datei mit
                     der Dateiendung "proj" und verwendet diese Datei.

Schalter:

  /help              Zeigt diesen Hilfetext an. (Kurzform: /? oder /h)

  /nologo            Startbanner und Copyrightmeldung nicht anzeigen.

  /version           Nur Versionsinformationen anzeigen. (Kurzform: /ver)

  @<Datei>           Befehlszeileneinstellungen aus einer Textdatei einfügen.
                     Wenn Sie mehrere Antwortdateien festlegen möchten,
                     müssen Sie jede Datei einzeln angeben.

  /noautoresponse    Die Datei "MSBuild.rsp" nicht automatisch einfügen.
                     (Kurzform: /noautorsp)

  /target:<Ziele>    Diese Ziele in diesem Projekt erstellen. Verwenden Sie ein
                     Semikolon oder ein Komma, um mehrere Ziele zu trennen,
                     oder geben Sie jedes Ziel einzeln an. (Kurzform: /t)
                     Beispiel:
                       /target:Resources;Compile

  /property:<n>=<v>  Diese Eigenschaften auf Projektebene festlegen oder
                     überschreiben.
                     <n> ist der Eigenschaftenname, und <v> ist der
                     Eigenschaftenwert. Verwenden Sie ein Semikolon oder ein
                     Komma, um mehrere Eigenschaften zu trennen, oder
                     geben Sie jede Eigenschaft einzeln an. (Kurzform: /p)
                     Beispiel:
                       /property:WarningLevel=2;OutDir=bin\Debug

  /logger:<Protokollierung>
                     Diese Protokollierung verwenden, um Ereignisse
                     von MSBuild zu protokollieren.
                     Wenn Sie mehrere Protokollierungen angeben möchten, geben
                     Sie jede einzeln an.
                     Die Syntax für <Protokollierung> ist:
                        [<Protokollierungsklasse>,]<Protokollierungsassembly>
                        [;<Protokollierungsparameter>]
                     Die Syntax für <Protokollierungsklasse> ist:
                        [<partieller oder vollständiger Namespace>.]
                        <Protokollierungsklassenname>
                     Die Syntax für <Protokollierungsassembly> ist:
                        {<Assemblyname>[,<starker Name>] | <Assemblydatei>}
                     Die <Protokollierungsparameter> sind optional und werden
                     genau so an die Protokollierung weitergegeben, wie
                     Sie sie eingeben. (Kurzform: /l)
                     Beispiele:
                       /logger:XMLLogger,MyLogger,Version=1.0.2,Culture=neutral
                       /logger:XMLLogger,C:\Loggers\MyLogger.dll;OutputAsHTML

  /verbosity:<Ebene> Legt den Ausführlichkeitsgrad der Informationen
                     im Ereignisprotokoll fest.
                     Die verfügbaren Ausführlichkeitsgrade sind: q[uiet],
                     m[inimal], n[ormal], d[etailed] und diag[nostic].
                     (Kurzform: /v)
                     Beispiel:
                       /verbosity:quiet

  /consoleloggerparameters:<parameters>
                     Parameter für die Konsolenprotokollierung.
                     (Kurzform: /clp)
                     Die verfügbaren Parameter sind:
                        PerformanceSummary - Anzeigen der für Aufgaben, Ziele
                        und Projekte verwendeten Zeit.
                        NoSummary - keine Anzeige der zusammengefassten Fehler
                        und Warnungen am Ende.
                        NoItemAndPropertyList - keine Anzeige derListe
                        der Elemente und Eigenschaften beim Start jedes
                        Projektbuilds.
                      Beispiel:
                        /consoleloggerparameters:PerformanceSummary;NoSummary

  /noconsolelogger   Die Standardkonsolenprotokollierung deaktivieren.
                     Ereignisse werden nicht in der Konsole protokolliert.
                     (Kurzform: /noconlog)

  /validate          Das Projekt mithilfe des Standardschemas validieren.
                     (Kurzform: /val)

  /validate:<Schema> Das Projekt mithilfe des Standardschemas validieren.
                     (Kurzform: /val)
                     Beispiel:
                       /validate:MyExtendedBuildSchema.xsd

Beispiele:

        MSBuild MyApp.sln /t:Rebuild /p:Configuration=Release
        MSBuild MyApp.csproj /t:Clean /p:Configuration=Debug

[mjustin]

Zitat von kaju74:

Hier sehe ich, das mit dem Parameter "/p:Configuration=Release" bestimmt werden kann, ob das Projekt als "Debug" oder
"Release" gebuildet werden kann. Sowas wollte ich auch in einem Verbund aus TeamCity und MSBuild machen, weiß aber bisher
nicht, wo ich das eintragen kann/soll.

TeamCity habe ich noch nicht mit Delphi getestet, wird ohne den Parameter nicht defaultmäßig das Release Target erzeugt?

Interessant wäre, welche Dateien man auf dem Buildserver benötigt, damit Delphi 200x und MSBuild dort benutzt werden können (die gesamte Delphi Installation oder nur einzelne Dateien). Hat Delphi's Installer nicht schon eine Option dafür ('Installation auf Buildserver')?

Viele Grüße,

[MaBuSE]

Zitat von mjustin:

TeamCity habe ich noch nicht mit Delphi getestet, wird ohne den Parameter nicht defaultmäßig das Release Target erzeugt?

sag ich doch

Zitat von mjustin:

Interessant wäre, welche Dateien man auf dem Buildserver benötigt, damit Delphi 200x und MSBuild dort benutzt werden können (die gesamte Delphi Installation oder nur einzelne Dateien). Hat Delphi's Installer nicht schon eine Option dafür ('Installation auf Buildserver')?

msbuild ruft "nur" den dcc32 auf. Du kannst also auf vieles verzichten. Aber ich denke der Aufwand lohnt nicht. Es ist schnell mal eine Datei zuviel weggelassen und dann funktioniert es nicht richtig.

Lizenzrechtlich bringt es dir auch nichts. Wenn Du einen BuildServer hast, der, z.B. über eien Dienst auf einem Server, Projekte entgegennimmt, compiliert und die erzeugten *.exe Dateien wieder zurückgibt, benötigst Du trotzdem für diesen BuildServer eine eigene Lizenz. Egal ob Du nur den dcc32 installiert hast oder nicht.

[mjustin]

Zitat von MaBuSE:

msbuild ruft "nur" den dcc32 auf. Du kannst also auf vieles verzichten. Aber ich denke der Aufwand lohnt nicht. Es ist schnell mal eine Datei zuviel weggelassen und dann funktioniert es nicht richtig.

Lizenzrechtlich bringt es dir auch nichts. Wenn Du einen BuildServer hast, der, z.B. über eien Dienst auf einem Server, Projekte entgegennimmt, compiliert und die erzeugten *.exe Dateien wieder zurückgibt, benötigst Du trotzdem für diesen BuildServer eine eigene Lizenz. Egal ob Du nur den dcc32 installiert hast oder nicht.

Die dproj Dateien verweisen auf spezielle DLLs die im Delphi bin Verzeichnis liegen - die braucht man dann auch auf dem Buildserver. Auch die Suchpfade sind nicht explizit im proj File enthalten, und die Platzhalter müssen irgendwie aufgelöst werden ...

Eine weitere Lizenz braucht man nicht, Delphi darf man auch mehrfach installieren (Workstation, Laptop, VM, ...) wenn man eine gültige Lizenz hat.

Cheers,

[kaju74]

Hallo.

Tja, das Problem schein hier TeamCity zu sein...dort finde ich nämlich keine Möglichkeit, den Parameter an MSBuild beeinflussen zu können. Dehalb hatte ich in den jeweiligen .dproj-Projketen geguckt, wie man das dort angibt...muss ich nochmal gucken, obwohl ja "Release" schon richtig wäre. Wir haben auf unserem Build-Server das komplette Delphi installiert...kann mich jetzt nicht daran erinnern, ob es da eine spezielle Setup-Methode gab. Im Notfall müssen wir auf dem Server direkt was ändern können, wenn der Entwickler nicht da ist...daher die Komplettinstallation.

Danke für die Aufklärung der Abhängigkeiten der einzelnen MSBuild-Dateien...muss ich nochmal detailliert gucken.

Lieben gruß,
kaju

[MaBuSE]

Zitat von mjustin:

Eine weitere Lizenz braucht man nicht, Delphi darf man auch mehrfach installieren (Workstation, Laptop, VM, ...) wenn man eine gültige Lizenz hat.

Das ist nur teilweise richtig.

Du darfst Delphi mehrfach installieren und benutzen. -> "named user license"

Wenn Du auf Laptop und PC Delphi installierst und dann am Laptop mit Delphi arbeitest, während jemand anderer am PC mit Delphi arbeitet ist das nicht in Ordnung.

Wird der BuildServer von mehreren Programmierern genutzt, musst Du ihn lizensieren.

Wenn Du BELISE (Borland License Server) oder ELISE (Embacadero License Server) einsetzt wirst du gar nicht drumherum kommen. Da der Lizenzserver die Netzwerklizenzen dem BuildServer verweigert, wenn er nicht registriert ist.
Anders verhällt es sich mit "concurrent licenses", die sind nicht an einen Programmierer gebunden, sondern der Lizenzserver zählt nur die Anzahl der gleichzeitig verwendeten Lizenzen.

Ich habe mich mit diesem Thema ausführlich beschäftigt, da wir 43 Delphi Lizenzen haben.
Eine davon ist der BuildServer