Warum Delphi 64-Bit-IDE

[jaenicke]

Zitat von win568:

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.

Zitat von win568:

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.

Zitat von himitsu:

PS: Die eine alte Funktion von Delphi ist echt saublöd.
"Automatisch speichern beim Kompilieren" speichert nach dem erfolgreichen Kommpilieren, also erst nachdem Delphi abgestürzt ist, und somit war dann alles futsch.

Man sieht bereits beim Kompilieren, dass sich der Speicherknopf deaktiviert. Das Speichern passiert vor dem Kompilieren.

Zitat von himitsu:

Auch wird der "Desktop" nicht gespeichert (XE), wenn man "Speichert", sondern erst wenn man Delphi schließt.

Das stimmt. Das hat aber den Vorteil, dass es bei Abstürzen durch eine bestimmte offene Unit oder ein Projekt nicht gleich beim Start wieder einen Absturz gibt.

[win568]

Zitat von win568:

Wir haben eigen Experts entwickelt, die sowohl Packages als auch Monolithen "Out of Delphi" compilieren können.

Zitat von jaenicke:

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.

Zitat von win568:

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.

Zitat von jaenicke:

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