Python-скрипт для управления проектом C ++ - PullRequest
0 голосов
/ 21 января 2019

В моей команде я решил использовать скрипт Python3 для управления проектом, написанным на C ++.Таким образом, я использую скрипт для того, чтобы собрать всю функциональность над проектом в одном месте.Я использую его для:

  • запуска make
  • запуска теста make
  • compile docs
  • сбора статистики
  • проверки стиля кодирования

Например, я звоню: ./foo.py stat для сбора статистики.Внутри есть куча утилит.Я оперирую с ними, используя sys и os.

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

Вот вопросы:

  • Это обычная практика?
  • Если это не так, почему?
  • Какое лучшее решение?
  • Дополнительная информация

1 Ответ

0 голосов
/ 21 января 2019

Является ли использование сценариев Python для этих задач хорошим решением, мне кажется, что этот проект является специфическим для меня, и попытка ответить на такой вопрос может оказаться недостаточной. Позвольте мне все же попытаться немного классифицировать.

  • запуск make
  • запуск тестовой марки
  • скомпилировать документы

Вы должны спросить себя, почему недостаточно вызвать make, make test и make docs. Слой Python между ними кажется мне излишним, так как я не могу придумать сценарий, где он добавляет гораздо больше удобства. Если вызов make слишком сложен (например, из-за того, что нужно указать множество аргументов), я сначала попытался бы поработать над самим Makefile, чтобы упростить его использование.

  • сбор статистики

Имеет смысл для меня.

  • проверить стиль кодирования

«Стиль кодирования» означает очень много вещей, но когда вы пытаетесь применить соглашения об именах, длину функции или форматирование кода, я бы посоветовал вам использовать clang-tidy и clang -формат , чтобы не изобретать велосипед. Эти инструменты довольно мощные и могут управляться файлом конфигурации, который может быть частью вашего проекта. Если удобно вызывать эти инструменты из скрипта Python или использовать скрипт Python для генерации compile_commands.json, мне кажется, это нормально.

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

Чтобы прокомментировать некоторые из последних вопросов вашего поста,

  • Это обычная практика?

Небольшие скрипты для конкретных задач, таких как генерация статистики репо: да. Большой рукописный инструмент для управления сборками, выпусками, документацией: я бы сказал, нет.

  • Если нет, то почему?

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

...