Есть ли что-то еще, что я должен рассмотреть, добавив к этому, кроме правила очистки?
TL; DR : Вы должны предварительно запустить ccptest's autogen.sh сценария и включите все полученные файлы в ваш дистрибутив вместе со всеми остальными. Затем вы могли бы также рассмотреть вопрос об исключении правила для сборки cpputest/configure (я бы на самом деле его опускал).
Cpputest, очевидно, следует недавней тенденции исключения файлов, сгенерированных Autotools, из системы контроля версий. Это имеет смысл на первый взгляд, потому что эти файлы действительно могут быть сгенерированы из других, которые доступны из системы контроля версий. Это хорошо с точки зрения системы контроля версий, являющейся инструментом сопровождения и развития проекта. Это не отлично, однако, в отношении управления исходным кодом, используемого в качестве инструмента распределения .
Одна из целей проектирования Autotools в том, что они сами нужны только сопровождающим проекта. Запуск их не предназначен для того, чтобы быть частью обычного процесса сборки, который может нанять тот, кто просто хочет собрать и запустить программное обеспечение. Соответственно, пакеты распространения, подготовленные самими системами сборки Autotools, включают в себя все необходимые биты, чтобы сделать это возможным: сценарий configure, вспомогательные сценарии утилит, файлы Makefile.in, а иногда и несколько других разных файлов. Это форма, предназначенная для распространения.
В этом случае на Autotools оказывается меньше давления совместимости, чем на многие проекты, и это проявляется в более слабой совместимости между различными версиями AT. Если вы собираете систему сборки с другой версией AT, чем сами разработчики проекта, то вы можете столкнуться с ошибками. Вы определенно получите систему сборки с некоторыми отличиями от той, которую используют сопровождающие. Зачастую результат все равно строит проект без проблем, но иногда нет. Так что сделайте себе одолжение и обходите эту проблему.
Запуск этого make-файла делает то, что я хочу, но я не уверен, насколько надежны зависимости.
Сам make-файл выглядит довольно хорошо для меня. Основные вещи, которые я вижу, чтобы критиковать:
, правило для cpputest/cpputest_build/Makefile буквально разъясняет часть каталога вместо использования переменной $(CPPUTEST_BUILD_DIR).
список предварительных требований цели cpputest не должен включать cpputest/configure или $(CPPUTEST_BUILD_DIR)/Makefile. То, что они необходимы для процесса сборки, является второстепенным и уже устранено теми артефактами, которые перечислены в качестве предварительных условий целей, которые напрямую зависят от них. С точки зрения стиля, удобства обслуживания и общей практики, правила make должны содержать список только предварительных условий для целей.
Поскольку я рекомендую вместо этого распространять компоненты системы сборки чтобы все их перестроили, я бы также удалил правило для сборки cpputest/configure. Если вы последуете моему совету, то распространите предварительно созданный, поэтому пользователям не нужно его собирать. Отказ от правила и извлечение cpputest/configure из тех обязательных списков, в которых оно появляется, устранят небольшой риск того, что все упадет в случае зашифрования временных меток, что иногда может случиться, когда копируется исходное дерево.
As для правила clean, поскольку вы выполняете настройку cpputest под управлением верхнего уровня make, соответствующий способ очистки будет cd $(CPPUTEST_BUILD_DIR); make distclean. Однако, поскольку вы выполняете сборку из исходного кода, у вас также есть альтернатива - просто рекурсивно удалить каталог сборки. Обратите внимание, однако, что если вы продолжаете выполнять autogen.sh как часть процесса сборки, то сгенерированные файлы не ограничиваются каталогом сборки. В этом случае соответствующая чистка, вероятно, будет включать make maintainer-clean.