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

Question

Мы только что перешли с D7 на D2010 и обсуждаем вопрос об очистке путей проекта. У нас есть несколько каталогов с большим количеством файлов Pas, которые включены в некоторые пути проекта, но только несколько файлов фактически используются любым отдельным проектом.

Один из вариантов - полностью исключить пути к проектам и иметь только все используемые файлы в dpr.

Второй вариант - хранить только необходимые файлы в dpr и иметь пути проекта к каталогам для остальных файлов.

Есть ли аргумент для одного варианта над другим?

Answer 1

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

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

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

Answer 2

Наличие всех ваших модулей в явном виде в dpr значительно улучшает время компиляции, завершение кода, понимание ошибок и общую навигацию.
Это не мешает вам хранить ваши файлы в папках и подпапках, но не полагается на разные пути их поиска.
В большом проекте с миллионами LOC разница составляет .

Answer 3

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

Answer 4

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

Answer 5

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

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

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

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

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