Организация структуры папок при работе в Delphi

Когда я только пришёл работать в N два года назад, мне достался довольно старый проект на Дельфи 6, с которым до меня успели проработать программиста три. Мне очень понравилась идея организации структуры папок проекта. Работая с несколькими большими проектами я успел оценить по достоинству преимущества такого подхода. И именно о структуре папок я и хочу сегодня поговорить.

Все проекты у меня хранятся в одной папке C:\Work. Сюда извлекаются копии проектов из SVN-хранилища.

Сейчас я работаю с несколькими проектами, хранящимися в разных репозиториях, и папка Work у меня выглядит так:

c:\Work\Organizer - большой рабочий проект из первого репозитория
c:\Work\BigApplication - большой рабочий проект из второго репозитория
c:\Work\LazyProject - мой личный проект из репозитория code.google.com

Некоторые проекты довольно велики, и для компиляции требуют установки многих сторонних библиотек, причём строго определённых версий. На примере проекта Organizer я покажу внутреннюю структуру папок:

c:\Work\Organizer\Build - это каталог для скомпилированных файлов
c:\Work\Organizer\Components - это каталог с исходниками компонент необходимых для компиляции Organizer-a
c:\Work\Organizer\Organizer_src - каталог с исходниками самого проекта
c:\Work\Organizer\Docs - каталог для документации проекта
c:\Work\Organizer\Pictures - каталог с иконками и картинками для этого проекта

Подробнее о папке c:\Work\Organizer\Build.

Это единственная папка, которая не связана с SVN-хранилищем. Она создаётся перед первой компиляцией проекта. И именно в ней хранятся все генерируемые компилятором данные. Она имеет следующую структуру:

c:\Work\Organizer\Build\Bin - папка для .exe файлов
c:\Work\Organizer\Build\Bpl - папка для .bpl файлов
c:\Work\Organizer\Build\Dcp - папка для .dcp файлов
c:\Work\Organizer\Build\Dcu - папка для .dcu файлов
c:\Work\Organizer\Build\Res - папка для .res файлов

Для автоматической сборки проекта на работе я использую want. Именно want создаёт папку Build со всей вложенной структурой, компилирует все библиотеки и связанные проекты, складывает .dcu, .bpl, .dcp и .exe в соответствующие папки. И он же копирует .res и .dfm файлы в папку Res. Delphi к сожалению такие задания выполнять не умеет. Использованию want я как-нибудь посвящу отдельный пост.

 

А теперь собственно о преимуществах:

1) Я знаю где находятся все, абсолютно все файлы проекта.
2) Я легко могу перекомпилировать любой из проектов, включая все необходимые ему библиотеки с нужными директивами(спасибо want'у). Причём в любой из версий(спасибо SVN'у).
3) Больше не возникает ситуаций, когда в путях попадаются дублирующиеся .dcu или .bpl файлы.
4) Благодаря продуманной структуре рабочих папок, переключение между проектами(версиями одного проекта), использующими разные(чаще даже несовместимые) версии компонент, занимает несколько минут.
5) Подготовка нового рабочего места для работы с любым из проектов(компиляция и установка всех компонент) занимает где-то час, причём большая часть времени уйдёт на извлечение исходников из репозитория.
6) я легко могу хвастаться удобством своего рабочего места. =)

Читать дальше..

Решилась проблема с pFibDataset.Locate

Проблема с Locate в pFibDatasetе разрешилась путём перекомпиляции FibPlus без директивы FAST_LOCATE. Проблема с невалидными букмарками указывающими на незафетченную запись была обойдена путём использования стандарного метода ReOpenLocate(точно уже не помню?). После устранения проблем Фибы стали радовать стабильной работой.

Я полностью закончил переводить Финансовый модуль с BDE на Fib Plus(не прошло и полгода:>). Ответственные за тестирование лица удивлённо разводят руками и говорят что ошибок пока найти не могут. Жду когда модуль Финансов официально получит статус стабильного, а также премию и процент с первых продаж. =)

Не за горами портирование с BDE на FibPlus'ы модуля Документов.

Портировать на FibPlus-ы получилось не в пример приятнее чем могло бы быть с ibx-ами. Наличие отдельных транзакций для чтения и записи существенно упростило переход, а также наличие у FIB-ов флага AutoCommit. А возможность динамически генерировать SQL-ы по имени таблицы и первичному ключу избавила от необходимости проверять запросы у огромного количества Dataset-ов.

А пока что продумываю возможности безболезненного перевода приложений. И по всем параметрам получается, что до появления Юникодной версии Delphi, без извращений ничего стопроцентно-путного сделать не получится.

Читать дальше..