Настройка путей IDE Delphi для продуктивной работы

Недавно зашел к товарищу в гости, и тот пожаловался, что его проект компилируется почти полторы минуты, хотя по размерам относительно небольшой, да и окно Code Completition первый раз после компиляции проекта открывается непозволительно долго. Покопавшись в настройках среды, я обнаружил причину столь медленной работы. На мои замечания товарищ ответил тем, что в хелпе информации по вопросу организации работы сторонних библиотек в IDE крайне мало, после чего родилась эта заметка. Возможно, профессионалам она не пригодится, но кому-то поможет ускорить работу.
Не секрет, что точность, качество и скорость работы любым инструментом зависят не только от того, кто его фирма-изготовитель и из каких материалов сделан инструмент, но и от того, правильно ли закручена какая-нибудь маленькая гаечка в механизме его настройки. Так и с IDE Delphi могут произойти скоростные метаморфозы, стоит только чутка ошибиться с настройками. Сегодняшний разговор затронет плохоосвещенную в документации вещь – настройку путей. А между тем, при правильной настройке путей можно значительно выиграть в скорости компиляции и сборки проекта. Но начну с начала.

Сама по себе пустая как барабан IDE работает хорошо. Проблема возникает, когда в среду устанавливается много сторонних компонентов. Чтобы они работали, необходимо в путях указать их местоположение. Разработчики тоже люди образованные, до девяти считать умеют, поэтому думают, что логичнее всего разные библиотеки хранить в различных папках. В целом, это правильно, однако со временем путей набирается так много, что IDE начинает существенно притормаживать. Самым простым и легким способом дать пинка неповоротливому созданию – отключить в проекте лишние пакеты. Однако если большинство библиотек каким-либо образом задействовано в ваших проектах, можно поступить следующим абсолютно нехитрым образом. Все DCU ото всех библиотек мы достаем из их локальных папок, помещаем в одну папку (назовем её DCUFolder) и прописываем её в Library Path, а упоминания о путях к папкам этих библиотек, напротив, удаляем из Library Path. При этом, данные библиотеки должны быть собраны с соответствующими релизу опциями компиляции, т.е. без отладочной информации, локальных символов и т.д. Таким образом, при компиляции проекта у вас не будет постоянно проверяться валидность DCU, что при большом количестве библиотек занимает существенное время. Ну а при билде проекта не будут перестраиваться библиотечные модули. Для отладки, неплохо бы иметь также папку с названием DCUDebugFolder, куда положить собранные с отладочной информацией библиотеки. Далее эту папку нужно прописать в Debug DCU Path. А для удобной навигации по исходным текстам - папки, в которых хранятся библиотеки, надо добавить в Browsing Path. Собственно говоря, это все.

Теперь несколько замечаний. При такой конфигурации есть принципиальный минус. Он заключается в том, что если вы в Вашем проекте также активно правите какой-то библиотечный модуль, то эти изменения автоматически не появятся в вашей программе без дополнительных телодвижений: вам необходимо в файле проекта библиотеки обязательно указать DCUFolder, куда класть скомпилированные библиотечные модули, добавить проект библиотеки в Вашу группу проектов и создать зависимость главного проекта от этого библиотечного проекта. Тогда при нажатии на F9, IDE сначала проверит, не следует ли скомпилировать библиотеку, и только после этого соберет основной проект, который уже окажется актуальным. Возникает вопрос, а как же быть, если мы хотим собрать некий релиз программы с нашими библиотеками, но так, чтобы были использованы другие опции компиляции. При этом хотелось бы не испортить наши скомпилированные библиотеки, лежащие в DCUFolder, поскольку нам они ещё нужны. В этом случае есть несколько путей. Самый универсальный, подходящий и для старых версий Delphi, и для последних, использующих MsBuild – создать dcc32.cfg файл в каталоге проекта, в котором описать необходимые настройки, а также пути до всех перестраиваемых библиотек (это, пожалуй, самая трудоемкая задача). В этом файле следуют также указать две опции -ERelease\ -NRelease\Dcu, которые заставят компилятор создать библиотеки и сам файл в отдельных папках, не создавая конфликт с другими проектами. Далее можно написать простенький пакетный файл, который бы вызывал dcc32.exe для компиляции Вашего проекта. Dcc32.cfg, находящийся в текущей папке, будет автоматически подхвачен компилятором и перекроет его стандартные настройки. Библиотеки откомпилируются с необходимым опциями и будут положены в отдельные папки. При этом сам файл проекта не меняется и не меняет настроек среды. Конечно, с появлением MSBuild многие задачи автоматической сборки проекта упрощаются. Но это уже тема для отдельного разговора.
Хочу также отметить, что в IDE Delphi существует баг, или скажем так недокументированная фича, когда перестает работать очень удобная и широко используемая команда Find Declaration (также известная как Ctrl + Left Click или Alt + Up). С чем это связано, почему-то затрудняются сказать и сами разработчики IDE, ответы в профильных конференциях уклончивые, на QualityCentral тикет помечен многообещающим словом Reported. Так вот, если вы все сделали правильно, то поиск декларации пропасть не должен. Но если же это все-таки произошло, и некоторые модули сторонних библиотек перестали открываться по щелчку мыши, но открываются по Ctrl + Enter, то в этом случае попробуйте удалить КЭШа проекта (*.identcache), как пишут сами разработчики, что, впрочем, не помогает, или удалить и перекомпилировать dcu файлы этих модулей, как это делаю я. Это помогает =). Очевидно, что эта особенность связана с рассинхронизацией исходного кода и DCU файла (точно сказать не берусь, так как формат dcu недокументирован). В итоге, устаревший файл DCU портит всю малину. Вот, собственно и все, о чем я хотел вам поведать.