Portable Build Environment

Question

Я пытаюсь выяснить, как определить мою среду сборки.

• У меня есть несколько многоразовых автономных модулей, разработанных на их собственных графиках выпуска.
• У меня также есть несколько клиентов, у каждого из которых есть собственное пользовательское приложение, использующее разные версии каждого повторно используемого модуля.
• Я использую g ++/make-файлы для моей системы сборки

• Мне нужно сделать его переносным для Cygwin и Linux.

  1. Предположим, что каждый модуль/клиент построен с собственной Makefile Как я могу настроить мой Makefiles динамически указывать правильную версию зависимость?

  2. Как я могу настроить CM-репо, чтобы команды разработчиков для каждого проекта и модуля работали независимо и не нуждались в большой ручной настройке каждый раз, когда они создают новую ветку?

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

./fooLibrary 
    ./include 
    ./lib 
./barLibrary 
    ./include 
    ./lib 
./plugins 
    ./pluginX 
     ./include 
     ./lib 
    ./pluginY 
     ./include 
     ./lib 
    ./pluginZ 
     ./include 
     ./lib 
./projects 
    ./customer1 
     ./bin 
     ./obj  
./projects/customer2 
     ./bin 
     ./obj  
./projects/unittests 
     ./bin 
     ./obj  

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

./fooLibrary 
     ./src 
     ./1.0 
      ./include 
      ./lib 
     ./1.1 
      ./include 
      ./lib 
     ./1.2 
      ./include 
      ./lib 
     ./1.2.1 
      ./include 
      ./lib 

Я просто пытаюсь сохранить его простым для команды разработчиков.

EDIT: Важно отметить, что у меня еще нет работы. Я чувствую, что я пытаюсь сделать что-то правильно, но я издеваюсь, пытаясь понять это правильно.

Answer 1

Что касается части CM, если вы используете GIT, у вас может быть один главный репозиторий для верхнего каталога и базовой системы сборки и submodules для каждого подпроекта.

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

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

Для независимой от платформы системы сборки я предлагаю CMake. Он может обрабатывать как конфигурацию, так и генерировать make-файлы для создания, для большего количества платформ и компиляторов, чем вам, вероятно, понадобится.

Я надеюсь, что любое из этого имеет смысл для вас.