Die Fremdkomponenten direkt im Projekt mit zu kompilieren macht keinen Sinn. Binde diese doch einfach in kompilierter Form ein, dann hast du bei der Projektgröße keinerlei Probleme in der Richtung mehr.
Ob die Fremdkomponenten als
BPL oder direkt in die EXE kommen, ist dabei egal,
Aber der größte Vorteil ist, dass man diese Komponenten auch ohne Debuginfos kompilieren kann (ohne extra in deren Units das deaktivieren zu müssen), während der eigene Code mit Debuginfos kompiliert werden kann,
abgesehn davon dass das Kompilieren des eigenen Programms dann schneller geht (und das "Speicherleck" im Inlinecompiler nicht stört).
Darum gehörten
PAS und
DCU auch in separate Suchpfade -> einmal für den Compiler und einmal für den Debugger.
Letzterer dafür, wenn man die Komponenten mit Debuginfos kompiliert hatte, aber das Programm nur mit DCUs oder BPLs kompiliert hat.
Zitat:
Arbeitsspeicher habe ich genug (40GB).
Ja und? Ich hab meistens 50 GB frei (von 100GB)
und "haben" oder "frei haben" ist erstmal ein großer Unterschied, wobei dieses hier nur für das gesammte System gilt,
aber nicht für einzelne Prozesse (Programme).
Die Delphi-
IDE ist 32 Bit und hat daher nur 2 GB virtuellen Speicher für seinen Prozess. OK, seit paar Jahren fast 4 GB (3 GB in einem 32 Bit-Windows), da man diese
Option inzwischen aktiviert hat.
Und selbst mit 1 GB
RAM könnte man locker auch die 4 GB nutzen, wenn die Auslagerungsdatei groß genug ist.
Der Inline-Compiler nutzt den Speicher des
IDE-Prozesses.
Wenn man über die Console kompiliert (DCC32), dann hat man noch bissl mehr freien Speicher, im Prozess.
Und eine Projektgruppe, mit zuvielen Projekten, kann/muß man dann eben stückchenweise kompilieren (nicht Alles auf einmal) ... wobei es auch hier über die Console besser geht, da jedes Projekt seinen eigenen DCC32 bekommt. (selbst wenn man die Projektgruppe via MSBUILD zusammen erstellen lassen würde)