Автоинструменты: должны ли config.guess, depcomp или ltmain.sh храниться в репозитории SVN? - PullRequest
2 голосов
/ 16 декабря 2010

Я занимаюсь проектом и вижу в хранилище subversion некоторые файлы, которые относятся к дистрибутиву libtool и automake, такие как config.guess, depcomp или ltmain.sh.Я считаю, что это просто неправильно, потому что, когда я делаю проверку, у меня должны быть установлены автоинструменты на моем компьютере и выполнить автореконфекцию.

Что ты думаешь?Я пропускаю смысл наличия этих файлов в хранилище?

Ответы [ 3 ]

6 голосов
/ 16 декабря 2010

Как правило, у вас не будет тех в вашем репозитории SVN. Обычно у вас есть autogen.sh, который воссоздает его по требованию. Ваш инстинкт не хранить потенциально устаревшие файлы хорош. Если кто-то вносит изменение в configure.ac, а кто-то еще проверяет все с помощью configure, изменение не будет иметь значения.

4 голосов
/ 20 декабря 2010

Почти все, что может быть сгенерировано - и к ним относятся depcomp и т. Д. - не должно быть частью отслеживаемого исходного хранилища.

2 голосов
/ 25 декабря 2010

Чистая теория заключается в том, что вы не должны помещать файлы, которые вы можете восстановить, в систему контроля версий. Поскольку вы можете воссоздать эти файлы, используя autoreconf -i или аналогичный, это применимо в этом случае.

Причина, по которой многие люди все еще делают это (помимо, возможно, невежества), заключается в том, что это может создать значительную дополнительную нагрузку на разработчиков. Если, скажем, у вас более крупный проект с открытым исходным кодом с десятками разработчиков и сотнями заинтересованных подписчиков, у каждого будет установлена ​​другая версия autoconf, automake, libtool, autopoint и т. Д. В простых случаях это не должно иметь значения. На практике это так, и это может создать серьезные головные боли и отвлечь потенциальных участников проекта.

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

...