Добавление файлов в файл DPR по сравнению с путями проекта в Delphi 2010

Я бы поспорил за включение всех файлов, которые использует проект, в сам проект. Это улучшит производительность «Insights», гарантируя, что используемые единицы являются частью проекта. Кроме того, это позволит вам более легко управлять своим кодом в Менеджере проектов. Наличие больших сложных путей хрупко, и с ними трудно справиться.

Комментарии об ускорении Insights меня заинтриговали, и я попробую, но до сих пор я никогда не включал общие блоки в проекты, в которых они использовались. Вместо этого я создал пакеты для каждой библиотеки и добавил их в группу проекта (в основном только для организационных целей, т.е. я никогда не компилирую их как пакеты времени выполнения). Я обнаружил, что этим легче управлять (особенно со всеми недавними улучшениями в диспетчере проектов), чем помещать все файлы в один проект, поскольку иерархии папок внутри отдельных (пакетных) проектов не будут такими глубокими, и особенно там нет ".. "-уровень таким образом.

Я выступаю за отделение «библиотечных модулей» от «модулей проекта» и сохранение всех «библиотечных модулей» в пути поиска со всеми символами « единицы проекта »в файле проекта. И вот почему:

• Наши отраслевые проекты - это большие, почти миллионы LOC-проектов, но помимо них существуют буквально сотни более мелких проектов для всякого рода крошечных мелочей. Наличие «библиотечных модулей», доступных в пути поиска, позволяет действительно легко использовать эти модули, не добавляя их в проект: одним шагом меньше, чем нужно!
• Использование пути поиска упрощает перемещение файлов PAS. Для меня это имеет большое значение, поскольку я нахожусь в процессе реорганизации всей нашей «среды сборки», чтобы лучше использовать системы контроля версий.
• Когда вы меняете один из совместно используемых модулей, и он становится зависимым от другого совместно используемого модуля, вам не нужно обновлять множество проектов, они просто работают.
• Я бы никогда не подумал о добавлении сторонних компонентов (или компонентов VCL) в свой проект, так зачем же добавлять в проект мои «библиотечные модули»? Нам нужно где-то провести черту, потому что, если мы добавим в проект абсолютно все файлы в надежде на более быстрое время компиляции, мы получим неуправляемо большие проекты!
• Delphi автоматически изменяет имена файлов в своем DPR-файле на относительные имена файлов. Из-за этого вы не можете переместить свой проект с его текущей позиции.Теперь попробуйте «разветвить» и сохранить две копии проекта одновременно на одной машине («выпуск» и «незавершенная работа»). (это я готовлю среду сборки для GIT с единственной целью - иметь возможность BRANCH).

Для справки, мои «библиотечные модули» - это те модули, которые используются в несвязанных проектах (подумайте: компоненты и утилиты).

Причины не включать все файлы в проект:

• меньше времени на открытие/закрытие проекта (формы и датамодули требуют дополнительного времени)
• быстрее рефакторинг файлов (переименование/перемещение файлов и каталогов не требует редактирования всех проектов)
• легче найти блоки, которые являются основными требованиями и точкой входа для логики приложения (использует MyInterfaces, MyTypes, MymMainUnit;)

И эта запись QC:

Отчет №: 77687 (RAID: 273031)
Статус: Открыт Редактирование в .dpr становится медленнее по мере увеличения количества единиц в проект http://qc.embarcadero.com/wc/qcmain.aspx?d=77687

Обновление: Теперь я знаю, что есть много способов открыть файл проекта :) - Но я имел в виду, что в dpr с 500 ссылками на юниты трудно найти "важные" (или "основные") юниты, которые являются отправной точкой для углубления в источник - и легче исследовать код, если это "легкий" файл проекта, который содержит только необходимые ссылки на юниты.