Autor |
Beitrag |
Nersgatt
Beiträge: 1581
Erhaltene Danke: 279
Delphi 10 Seattle Prof.
|
Verfasst: Di 08.07.14 10:35
Moin!
Ich verwende eine Batchdatei, um alle Projekte meiner Projektgruppe mit MSBuild zu erzeugen und im Anschluss ein Setup mit Innosetup auszuspucken.
Wenn nun beim Kompilieren einer Komponente etwas fehl schlägt, hätte ich gern, dass der gesamte Batchablauf abgebrochen wird. Jetzt wird einfach von MSBuild das nächste Projekt der Projektgruppe erzeugt und die eventuellen Fehlermeldungen verschwinden in der Konsole außerhalb des Sichtfeldes.
Ist es möglich, MSBuild irgendwie mitzuteilen, bei einem Fehler den Buildvorgang abzubrechen?
Danke!
Jens
_________________ Gruß, Jens
Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du. (Mahatma Gandhi)
|
|
Martok
Beiträge: 3661
Erhaltene Danke: 604
Win 8.1, Win 10 x64
Pascal: Lazarus Snapshot, Delphi 7,2007; PHP, JS: WebStorm
|
Verfasst: Di 08.07.14 11:02
Meinst du auf der MSBuild-Seite oder im Batch?
Batchseitig wäre das "IF ERRORLEVEL 1" etc.
MSBuild hat da laut Tante Google wohl RunEachTargetSeparately="false" und StopOnFirstFailure="true" (so dass ein Fehler in einem Target alle abbricht), aber da kenn ich mich nicht aus. Makefiles haben das als Defaultverhalten
_________________ "The phoenix's price isn't inevitable. It's not part of some deep balance built into the universe. It's just the parts of the game where you haven't figured out yet how to cheat."
|
|
Nersgatt
Beiträge: 1581
Erhaltene Danke: 279
Delphi 10 Seattle Prof.
|
Verfasst: Di 08.07.14 11:17
Ich meine MSBuild-seitig.
Mit den Optionen komme ich nicht so recht weiter. Google spuckt nur Beiträge raus, wie diese Optionen in sln-Dateien eingebunden werden. Aber ich hab ja Delphi und nicht VS.
Mein Aufruf in der Batch sieht einfach so aus, dass ich die Projektgruppe übergebe: msbuild c:\Pfad\zur\Projektgruppe.groupproj /nologo /p:config=release
Ich hatte nun gehofft, dass man sowas wie StopOnFirstFailure als Parameter an msbuild übergeben kann. Aber in der Hilfe finde ich dazu nichts...
_________________ Gruß, Jens
Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du. (Mahatma Gandhi)
|
|
Martok
Beiträge: 3661
Erhaltene Danke: 604
Win 8.1, Win 10 x64
Pascal: Lazarus Snapshot, Delphi 7,2007; PHP, JS: WebStorm
|
Verfasst: Di 08.07.14 11:29
So wie ich das lese ist das in Solutions sogar schwerer, die bauen davon immer erst Projekte. Dort dann als Attribute im MSBuild-Element des Targets. Keine Ahnung ob so eine Änderung Delphi laden+speichern überlebt...
Hast du mal eine Beispielprojektgruppendatei (was für ein Wort)?
_________________ "The phoenix's price isn't inevitable. It's not part of some deep balance built into the universe. It's just the parts of the game where you haven't figured out yet how to cheat."
|
|
Nersgatt
Beiträge: 1581
Erhaltene Danke: 279
Delphi 10 Seattle Prof.
|
Verfasst: Di 08.07.14 11:49
Eine Projektgruppendatei sieht so aus:
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: 47: 48:
| <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <PropertyGroup> <ProjectGuid>{7E408A96-2ED6-4B4F-A929-B212522A4284}</ProjectGuid> </PropertyGroup> <ItemGroup> <Projects Include="Project2.dproj"> <Dependencies/> </Projects> <Projects Include="Project3.dproj"> <Dependencies/> </Projects> </ItemGroup> <ProjectExtensions> <Borland.Personality>Default.Personality.12</Borland.Personality> <Borland.ProjectType/> <BorlandProject> <Default.Personality/> </BorlandProject> </ProjectExtensions> <Target Name="Project2"> <MSBuild Projects="Project2.dproj"/> </Target> <Target Name="Project2:Clean"> <MSBuild Projects="Project2.dproj" Targets="Clean"/> </Target> <Target Name="Project2:Make"> <MSBuild Projects="Project2.dproj" Targets="Make"/> </Target> <Target Name="Project3"> <MSBuild Projects="Project3.dproj"/> </Target> <Target Name="Project3:Clean"> <MSBuild Projects="Project3.dproj" Targets="Clean"/> </Target> <Target Name="Project3:Make"> <MSBuild Projects="Project3.dproj" Targets="Make"/> </Target> <Target Name="Build"> <CallTarget Targets="Project2;Project3"/> </Target> <Target Name="Clean"> <CallTarget Targets="Project2:Clean;Project3:Clean"/> </Target> <Target Name="Make"> <CallTarget Targets="Project2:Make;Project3:Make"/> </Target> <Import Project="$(BDS)\Bin\CodeGear.Group.Targets" Condition="Exists('$(BDS)\Bin\CodeGear.Group.Targets')"/> </Project> |
Ich hab mal versucht, hier die Optionen einzufügen:
XML-Daten 1: 2: 3: 4: 5: 6: 7: 8: 9:
| <Target Name="Project2"> <MSBuild Projects="Project2.dproj" StopOnFirstFailure="true"/> </Target> <Target Name="Project2:Clean"> <MSBuild Projects="Project2.dproj" Targets="Clean" StopOnFirstFailure="true"/> </Target> <Target Name="Project2:Make"> <MSBuild Projects="Project2.dproj" Targets="Make" StopOnFirstFailure="true"/> </Target> |
Das hat sich aber überhaupt nicht auf das Verhalten von MSBuild ausgewirkt.
_________________ Gruß, Jens
Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du. (Mahatma Gandhi)
|
|
Martok
Beiträge: 3661
Erhaltene Danke: 604
Win 8.1, Win 10 x64
Pascal: Lazarus Snapshot, Delphi 7,2007; PHP, JS: WebStorm
|
Verfasst: Di 08.07.14 12:56
So wie ich das verstanden hab, muss das da dran:
XML-Daten 1: 2: 3:
| <Target Name="Build" RunEachTargetSeparately="false"> <CallTarget Targets="Project2;Project3"/> </Target> |
Scheint das Makefile-Äquivalent von Abhängigkeiten vs. Direktaufruf zu sein.
_________________ "The phoenix's price isn't inevitable. It's not part of some deep balance built into the universe. It's just the parts of the game where you haven't figured out yet how to cheat."
|
|
Nersgatt
Beiträge: 1581
Erhaltene Danke: 279
Delphi 10 Seattle Prof.
|
Verfasst: Di 08.07.14 13:02
Ne, nicht wirklich. Dann bricht MSBuild gleich mit einem Fehler ab:
Quelltext 1:
| error MSB4066: The attribute "RunEachTargetSeparately" in element <Target> is unrecognized. |
_________________ Gruß, Jens
Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du. (Mahatma Gandhi)
|
|
jaenicke
Beiträge: 19285
Erhaltene Danke: 1743
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Di 08.07.14 13:09
Wir verwenden Jenkins und benutzen darin auch MSBuild um unsere Projekte zu erstellen. Wenn dort ein Fehler in einem Projekt der Projektgruppe auftritt, bricht der Build auch direkt ab.
Wie Jenkins das macht, weiß ich nicht, das habe ich mir nie angeschaut.
Die Projektdateien würde ich nicht manuell bearbeiten, da Delphi beim Auslesen und Ändern eher unvorhersehbare Ergebnisse liefert. Da dann jeweils mit Diffs herangehen zu müssen, nur weil man manuelle Änderungen drin hat, macht nur unnötig viel Arbeit.
Jenkins funktioniert sehr einfach und kümmert sich um den kompletten Build inkl. Fehleranalyse usw., wenn du das möchtest. Ich kann das nur empfehlen...
|
|
Nersgatt
Beiträge: 1581
Erhaltene Danke: 279
Delphi 10 Seattle Prof.
|
Verfasst: Di 08.07.14 13:34
jaenicke hat folgendes geschrieben : | Die Projektdateien würde ich nicht manuell bearbeiten, da Delphi beim Auslesen und Ändern eher unvorhersehbare Ergebnisse liefert. Da dann jeweils mit Diffs herangehen zu müssen, nur weil man manuelle Änderungen drin hat, macht nur unnötig viel Arbeit. |
Wenn das so geklappt hätte, ich mir kurz ein kleines Tools zusammengehackt, welches in einer Kopie der Projektdatei die nötigen Zeilen einfügt und damit dann MSBuild füttert.
Momentan behelfe ich mich halt damit, vorher die EXE-Dateien zu löschen. Dann schlägt spätestens der Innosetup-Compiler fehl, da er Dateien nicht findet, was ich dann mitbekomme.
_________________ Gruß, Jens
Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du. (Mahatma Gandhi)
|
|
Ralf Jansen
Beiträge: 4705
Erhaltene Danke: 991
VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
|
Verfasst: Di 08.07.14 13:52
Ich würde die bat Datei durch ein MSBuild proj Datei ersetzen. Wenn du dann dein ursprüngliches Project als BuildTarget hinzufügst solltest du dort dann StopOnFirstFailure einfach setzen können.
Zumindest mit einer Visual Studio Solution als Build Target funktioniert das.
In etwa
XML-Daten 1: 2: 3: 4: 5: 6: 7: 8: 9: 10:
| <?xml version="1.0" encoding="utf-8"?> <Project DefaultTargets="Build;Setup" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="12.0"> <Target Name="Build"> <MSBuild Projects="DeineSolution.sln" Targets="Rebuild" Properties="DeineGewünschteKonfiguration" StopOnFirstFailure="true"/> </Target>
<Target Name="Setup"> <Exec Command=""$(MSBuildProgramFiles32)\Inno Setup 5\iscc.exe" deinLiebesInnoSetupSetup.iss" /> </Target> </Project> |
|
|
Nersgatt
Beiträge: 1581
Erhaltene Danke: 279
Delphi 10 Seattle Prof.
|
Verfasst: Di 08.07.14 14:39
Ralf Jansen hat folgendes geschrieben : | Ich würde die bat Datei durch ein MSBuild proj Datei ersetzen. Wenn du dann dein ursprüngliches Project als BuildTarget hinzufügst solltest du dort dann StopOnFirstFailure einfach setzen können. |
Oh, super, jetzt kommen wir der Sache näher. Diese Möglichkeit kannte ich nicht.
Es funktioniert jetzt, mit der Einschränkung, dass es nur dann geht, wenn ich in der .proj-Datei bei Projects=... alle Projekte einzeln angebe. Wenn ich die Projektgruppendatei angebe, macht er weiterhin bei einem Buildfehler eines einzelnen Projektes mit den anderen Projekten weiter.
Das sieht dann so aus:
Quelltext 1:
| <MSBuild Projects="./projekt1/projekt1.dproj;./projekt2/projekt2.dproj;./projekt3/projekt3.dproj" Properties="config=release" RunEachTargetSeparately="false" StopOnFirstFailure="true" ContinueOnError="false"/> |
Damit klappt es.
Ist zwar auch noch nicht schönste Lösung, aber schon nah dran.
_________________ Gruß, Jens
Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du. (Mahatma Gandhi)
|
|
jaenicke
Beiträge: 19285
Erhaltene Danke: 1743
W11 x64 (Chrome, Edge)
Delphi 11 Pro, Oxygene, C# (VS 2022), JS/HTML, Java (NB), PHP, Lazarus
|
Verfasst: Di 08.07.14 16:15
Wobei du dann immer noch das Auschecken usw. selber erledigen muss. Das alles würde dir Jenkins abnehmen. Zudem hättest du dann die Gewissheit, dass auch wirklich dein Stand im Repository so funktioniert und im Setup ist und du nicht lokal eine Datei vergessen hast einzuchecken usw. und Unittests kannst du z.B. auch automatisch vorher laufen lassen.
Denn das ggf. nicht saubere Projektverzeichnis ist bei der manuellen Lösung immer noch ein Problem, selbst wenn du einen Fehler beim Kompilieren dann am Ende mit den Änderungen siehst. Das ist genau der Grund weshalb ich meine Batch-Lösung nicht mehr weiterentwickelt habe.
Natürlich kann man das alles auch manuell in eine Batchdatei oder das MSBuild Projekt stecken... aber das ist finde ich unnötiger Aufwand und schlechter wartbar.
|
|