Wir haben eigen Experts entwickelt, die sowohl Packages als auch Monolithen "Out of Delphi" compilieren können.
Dafür gibt es auch ein Häkchen in den Projektoptionen, dass msbuild extern verwendet werden soll.
Haben wie bereits versucht, aber hier ist das gleiche Problem, das dem msbuild der Speicher ausgeht. Daher verwenden wir den fastdcc32, unsichtbar ausgeführt in einer Dos Kommandozeile. Die Ergebnisse werden geholt und in einer eigenen übersichtlicheren Liste, in der man Warnings, Errors filtern und farblich trennen kann, dargestellt.
Hmm. Welche Komfortfunktion ?? Die Packages bauen aufeinander auf. Dadurch sind diese in einer Gruppe zu halten, da viele Programmierer an unterschiedlichen Dateien arbeiten und einchecken. Mit dem nächsten
Svn Abgleich müssen teilweise die Packages wieder neu erzeugt werden.
Dafür braucht man aber keine Projektgruppe mit allen Packages. Bei uns ist das z.B. unterteilt in die Packages mit gemeinsamen Units und Komponenten, die von den verschiedenen Projekten für Anwendungen und DLLs dann verwendet werden. Diese Packages werden per Kommandozeile installiert und mit msbuild erzeugt.
Beim Debuggen usw. haben wir dann nur die Projektgruppe oder das Einzelprojekt offen, an dem wir konkret arbeiten.
Würden wir das anders machen, hätten wir insbesondere bei Versionen wie XE6 deutliche Probleme gehabt. So funktionierte es selbst da schon recht gut und in den 10er Versionen haben wir so gut wie gar keine Probleme mehr damit.
Auch hier verwenden wir die Standardgruppen nicht. Wir haben sowohl statische Packages, also Packages die aufeinander aufbauen, als auch dynamische Packages (die unabhängig sind). Das Compilercenter checkt diese Abhängigkeiten und erzeugt die dynamischen, je nach Ressource auf der Maschine, parallel.
Da bei uns viele Programmierer gleichzeitig ab Code arbeiten und diese wiederrum in unterschiedlichen Packages Änderungen vornehmen, ist so ein Einspielen im Hintergrund auch nicht praktikabel