автоматизация сборки — как вы управляете большими зависимостями C ++ в командной среде?

ФОН

В течение моей карьеры я был удивлен тем, как много проектов я видел, где очень сложно скомпилировать и выполнить проект в Visual Studio. Источником проблемы обычно являются: отсутствующие зависимости, отсутствие документации, неработающие ссылки на проекты и т. Д.

Чтобы избежать этих головных болей, я стараюсь автоматизировать проекты / решения так, чтобы:

  1. среда выполнения автоматически настраивается, когда проект компилируется на компьютере разработчика (например, используйте пакетные сценарии для импорта отсутствующих ключей реестра Windows)
  2. при компиляции проекта правильные зависимости извлекаются автоматически (как на компьютере сборки & разработчик машины)

ЭТА ПРОБЛЕМА

На сегодняшний день у меня был достаточный успех с этим подходом. Однако недавно мне передали собственный проект C ++, который зависит от Microsoft Windows SDK. Во время компиляции проект использует переменные среды Windows для поиска отсутствующих зависимостей (например, Microsoft Windows SDK).

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

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

Я не хочу обсуждать преимущества того, чтобы разработчик конфигурировал среду разработки, но мне хотелось бы знать:

Учитывая существующую сегодня технологию (например, TFS), каков надежный и повторяемый подход к обработке больших зависимостей (например, Windows SDK) для проектов C ++ в командной среде?

ПОТЕНЦИАЛЬНЫЕ РЕШЕНИЯ

  1. продолжать использовать переменные среды
    • Adv: после того, как зависимости установлены, сборочная машина очень легко компилирует проекты
    • Dis: вам нужно потратить время на документирование, чтобы убедиться, что вы можете настроить машину для сборки с нуля (например, шаг 1: установить зависимость A, шаг 2: установить зависимость B и т. Д.)
    • Dis: Вы полагаетесь на магия переменные окружения должны указывать на правильную цель.
    • Dis: разработчик тратит время на настройку, когда они должны разрабатывать
  2. проверить зависимости в TFS
    • Adv: все хранится в одном централизованном месте
    • Adv: по замыслу система контроля версий хранит историю
    • Adv: в некотором смысле контроль над источниками делает вещи самодокументирующими
    • Dis: Компиляция на сборочной машине теперь занимает значительно больше времени, чем сборочная машина.
      рабочая область должна многократно извлекать Windows SDK из TFS
  3. Другой?

КОНТЕКСТ

  • Язык программирования: неуправляемый C ++
  • Контроль версий: TFS 2012
  • зависимости:
    • Microsoft Windows SDK (~ 416 МБ)
    • в домашних библиотеках
  • У меня ограниченные знания о том, как администрировать / настраивать машину сборки TFS.

РЕКОМЕНДАЦИИ

5

Решение

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

ссылка казалась очень полезной спасибо

1

Другие решения

Других решений пока нет …

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector