Есть ли какой-нибудь простой автоматический способ обнаружения всех исходных файлов, связанных с проектом Delphi?
Мне нравится делать резервную копию исходного кода, установленного для проекта, когда я выпускаю версию. Я использую резервные копии проектов GExperts, которые, кажется, собирают все файлы в менеджере проектов в ZIP-файл. Вы также можете добавить произвольные файлы в этот набор файлов, но я всегда осознаю тот факт, что я не обязательно получил все файлы. До тех пор, пока я специально не уйду к пунктам использования и не добавлю все модули, для которых у меня есть источники, в проект, я никогда не буду уверен в сохранении всех файлов, необходимых для воссоздания устанавливаемого / исполняемого файла.
Я думал о том, чтобы развернуть приложение для обхода проекта, проследить за всеми используемыми модулями, просмотреть все пути поиска и посмотреть, есть ли исходный файл для этого модуля, и создать список файлов для резервного копирования таким образом, но эй - может быть, кто-то уже сделал работу?
4 ответа
Вы должны (очень рекомендую) заглянуть в систему контроля версий.
например SVN (Подрывной), CVS
Это позволит вам контролировать ревизии всего вашего источника. Это позволит вам добавлять или удалять исходные файлы, откатывать слияние и все другие приятные вещи, связанные с управлением исходными файлами проекта.
Это сэкономит вам $%# один день.
Для получения списка всех модулей, скомпилированных в исполняемый файл, вы можете позволить компилятору сгенерировать файл MAP. Этот файл будет содержать записи для всех используемых единиц.
Я не уверен, спрашиваете ли вы о контроле версий или о том, как убедиться, что у вас есть все файлы.
Одна полезная утилита, которую я иногда запускаю, - это программа, которая создает DirList для всех файлов в моей выходной папке dcu. Изменение расширений с.dcu на.pas дает мне список всех файлов исходного кода.
Конечно, он пропускает файлы.inc и другие файлы, не относящиеся к.pas, но, возможно, эта мысль будет вам полезна?
Значение этой утилиты для меня заключается в том, что вторая служебная программа затем создает список всех файлов.pas в моем дереве исходников, которые не имеют соответствующих файлов.dcu. Это (после полной компиляции всех программ) обычно выявляет некоторые "ненужные" файлы.pas, которые больше не используются.
Вы можете интерпретировать свой вопрос двумя способами:
- Как я могу убедиться, что у меня есть резервные копии по крайней мере достаточно файлов, чтобы я мог построить проект
- Как я могу убедиться, что я делаю резервную копию не слишком много файлов, чтобы я все еще мог построить проект
Первый - убедиться, что вы вообще можете собрать систему, а второй - очистить неиспользуемые файлы.
Для обеих систем - система контроля версий, включающая отдельную систему сборки.
Затем вы - для каждого нового набора изменений - можете использовать эти шаги, чтобы убедиться, что оба условия выполняются:
- В вашей повседневной системе разработки проверьте новую версию исходного кода в вашей системе контроля версий.
- В вашей отдельной системе сборки получите последнюю версию вашей системы контроля версий.
- Сборка проекта по системе сборки; если это не удается, перейдите к шагу 1 и добавьте отсутствующие файлы в систему управления версиями из системы разработки.
- Начните удалять (один за другим) файлы из проекта, которые, по вашему мнению, не нужны, затем перестраивайте до тех пор, пока не произойдет сбой.
- Если сборка не удалась, восстановите этот конкретный файл из системы управления версиями, затем перейдите к шагу 3 со следующим кандидатом
- После успешной сборки у вас будет минимальный набор файлов.
- Теперь сделайте обзор файлов в вашей системе контроля версий и машине сборки.
- Пометьте файлы, которые находятся в вашей системе контроля версий, но не на вашем компьютере сборки, как устаревшие или удаленные.
Большинство систем управления версиями имеют хорошие способы создания различий между файлами в вашей разработке или системой сборки по сравнению с файлами в системе управления версиями (как правило, детализированными для каждого исторического момента времени, когда вы добавляли / удаляли / обновляли файлы в вашей системе управления версиями).).
Причина, по которой вам нужна отдельная система сборки (или две отдельные системы разработки), заключается в том, что вы хотите, чтобы они были независимыми: вы используете одну для разработки, а другую для проверки, все ли в порядке со сборкой.
Это первый шаг, который в будущем может потребоваться расширить в систему непрерывной интеграции (которая запускает модульные тесты, автоматически создает настройки продукта и многое другое).
--jeroen