Является ли использование сценариев Python для этих задач хорошим решением, мне кажется, что этот проект является специфическим для меня, и попытка ответить на такой вопрос может оказаться недостаточной. Позвольте мне все же попытаться немного классифицировать.
- запуск make
- запуск тестовой марки
- скомпилировать документы
Вы должны спросить себя, почему недостаточно вызвать make
, make test
и make docs
. Слой Python между ними кажется мне излишним, так как я не могу придумать сценарий, где он добавляет гораздо больше удобства. Если вызов make
слишком сложен (например, из-за того, что нужно указать множество аргументов), я сначала попытался бы поработать над самим Makefile
, чтобы упростить его использование.
Имеет смысл для меня.
- проверить стиль кодирования
«Стиль кодирования» означает очень много вещей, но когда вы пытаетесь применить соглашения об именах, длину функции или форматирование кода, я бы посоветовал вам использовать clang-tidy и clang -формат , чтобы не изобретать велосипед. Эти инструменты довольно мощные и могут управляться файлом конфигурации, который может быть частью вашего проекта. Если удобно вызывать эти инструменты из скрипта Python или использовать скрипт Python для генерации compile_commands.json
, мне кажется, это нормально.
В общем, для разных задач требуются разные инструменты, и я бы не стал создавать универсальную оболочку вокруг этих инструментов для создания целостного интерфейса, так как ваши скрипты на python со временем будут расти (как насчет контроля версий, упаковки для отладки / отпусти ...) пока не станет сложно управлять. Предпочитаю небольшие простые сценарии, которые выполняют одну задачу (кстати, это может иметь место в вашем подходе, я не могу сказать).
Чтобы прокомментировать некоторые из последних вопросов вашего поста,
Небольшие скрипты для конкретных задач, таких как генерация статистики репо: да. Большой рукописный инструмент для управления сборками, выпусками, документацией: я бы сказал, нет.
Кроссплатформенную функциональность, подобную этой, чрезвычайно трудно понять, так как существует бесконечное количество крайних случаев. Вращение ваших собственных инструментов может просто занять слишком много времени. Вместо этого, тщательная настройка существующих инструментов может быть наиболее эффективной стратегией. Кроме того, если вы пользуетесь установленными инструментами, (новые) разработчики, вероятно, будут к нему привыкать.