Является ли Mercurial .hgignore единственным вариантом для обработки сотен временных файлов, созданных при компиляции?

Два варианта:

1. Наилучший вариант - сделать сборку вне дерева, если можете. Это сборка, в которой объектные файлы размещаются вне дерева исходных текстов. Некоторые системы сборки, такие как CMake, поддерживают это напрямую. Что касается других систем, вам нужно быть удачливым, так как апстрим-проект должен был добавить поддержку для этого в своих Makefile или аналогичных.

2. Более общий вариант - указать Mercurial игнорировать определенные типы файлов, а не целые каталоги. По моему опыту, это хорошо работает.

Чтобы проверить второй вариант, я хотел скомпилировать Apache. Однако для этого требуется APR, поэтому я протестировал его. После проверки в чистом apr-1.3.8.tar.bz2 я сделал ./configure; make и посмотрел на результат hg status. Первые несколько узоров были легкими:

syntax: glob

*~
*.o
*.lo
*.la
*.so
.libs/*

Остальные новые файлы выглядят так, как будто они являются конкретными файлами, созданными в процессе сборки. Их тоже легко добавить:

% hg status --unknown --no-status >> .hgignore

Это также добавило .hgignore, поскольку я еще не запланировал его добавление. Удалив это, я получил этот .hgignore файл:

syntax: glob

*~
*.o
*.lo
*.la
*.so
.libs/*
.make.dirs
Makefile
apr-1-config
apr-config.out
apr.exp
apr.pc
build/apr_rules.mk
build/apr_rules.out
build/pkg/pkginfo
config.log
config.nice
config.status
export_vars.c
exports.c
include/apr.h
include/arch/unix/apr_private.h
libtool
test/Makefile
test/internal/Makefile

Я считаю, что это довольно надежный способ сделать это в Mercurial или любой другой системе контроля версий, если на то пошло.

Лучшим решением было бы исправить процесс сборки, чтобы он вел себя «хорошо», а именно позволял вам указать какой-то отдельный каталог для хранения промежуточных файлов (который затем можно было бы полностью игнорировать с помощью очень простой записи .hgignore. .. или даже не в структуре каталогов с контролем версий.

Как бы то ни было, я обнаружил, что в этой ситуации умный .hgignore - единственное решение, которое до сих пор работало для меня. Благодаря включению поддержки регулярных выражений это очень мощно, но также и сложно, поскольку шаблон, который не работает в одном каталоге, вполне может быть источником в другом.

По крайней мере, вы можете зайти в .hgignore и поделиться им со своими разработчиками. Таким образом, работа выполняется только один раз.

[Edit] По крайней мере, однако, возможно - как отмечал выше Мартин Гейслер - указать полный путь в вашем файле .hgignore; вы можете, следовательно, иметь test/Makefile в .hgignore, но Mercurial по-прежнему будет замечать новый test2/Makefile

Его процесс создания файла должен дать вам почти то, что вы хотите, и вы можете настроить это оттуда.

Один из вариантов - очистить рабочий каталог после проверки сборки.

make clean
hg status

Конечно, вы можете не захотеть очищать свой проект, если на его сборку уходит больше нескольких минут.

Если файлы, которые вы хотите отслеживать, уже известны hg, вы можете игнорировать все. Затем вам нужно использовать hg import для добавления патча, а не просто использовать команду patch (поскольку hg нужно знать, нужно ли отслеживать какие-то новые файлы).

Как насчет сценария оболочки (или любого другого), который рекурсивно просматривает ваш каталог сборки, находит каждый файл, созданный после запуска процесса сборки, и перемещает все эти файлы (конечно, вы можете указать исключения) в подкаталог cruft_dir. Тогда вы можете просто поместить cruft_dir/* в .hgignore.

РЕДАКТИРОВАТЬ: я забыл добавить, но это довольно очевидно, что этот сценарий оболочки запускается автоматически, как только ваша сборка завершается. Возможно, она даже вызывается последней командой в вашем файле Makefile / ant / any.