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

Two options:

1. The best option is to do an out of tree build, if you can. This is a build where you place the object files outside of the source tree. Some build systems, such as CMake, support this directly. For other systems, you need to be lucky since the upstream project must have added support for this in their Makefile or similar.

2. A more general option is to tell Mercurial to ignore specific types of files, not entire directories. This works well in my experience.

To test the second option, I wanted to compile Apache. However, it requires APR, so I tested with that instead. After checking in a clean apr-1.3.8.tar.bz2 I did ./configure; make and looked at the output of hg status. The first few pattens were easy:

syntax: glob

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

The remaining new files look like they are specific files generated by the build process. It's easy to add them too:

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

That also added .hgignore since I hadn't yet scheduled it for addition. Removing that I ended up with this .hgignore file:

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

I consider this a quite robust way to go about this in Mercurial or any other revision control system for that matter.

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

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

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

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

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

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

make clean
hg status

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

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

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

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