Как я могу установить и использовать компиляторы для встроенного C на внешнем сервере?

Question

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

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

Обеспокоенные области
1) Работа в сети с виртуальной машиной Windows.
2) Как / когда передать исходный код на сервер для сборки.

Справочная информация
Каждое семейство микропроцессоров, с которым работает наша команда разработчиков программного обеспечения, требует собственного компилятора, IDE и программиста.Это со временем создает много трудностей для преодоления.

1) Каждому разработчику требуется собственная, часто дорогая, лицензия.
2) Чтобы выбрать проект, запущенный другим разработчиком, требуется дополнительная осторожность, чтобы убедиться, что все настройки компилятора одинаковы.
3) Для поддержки устаревшего программного обеспечения могут потребоваться старые компиляторы, конфликтующие с установленным в данный момент компилятором.
... список можно продолжать и продолжать.

Редактировать: 7-10-2011 13:30 CST
1) Компиляторы, о которых я говорю, действительно являются кросс-компиляторами
2) Краткий список семейств процессоровв идеале эта система будет поддерживать: Motorola Coldfire, PIC и STM8.
3) Наш компилятор Coldfire является вариантом GCC, но мы должны поддерживать несколько его версий.Все остальные компиляторы используют специальный целевой компилятор, который не предоставляет плавающую лицензию.
4) Для решения littleadv я хотел бы создать внешний сервер сборки.
5) В настоящее время мы используем комбинацию SVN иGIT размещен в онлайн-хранилище для контроля версий.На самом деле это то, как я думал, что буду передавать файлы на сервер сборки.
6) Мы застряли с Windows для большинства компиляторов.

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

Имеет ли смысл создавать репозиторий для каждого компилятора, который будет включать в себя папки для сборки, исходного кода, включения, вывода и т. Д., А затем на стороне пользователя есть сценарии, которые заботятся о перемещении файлов изФайловая структура IDE для требуемой структуры для компилятора?Этот подход не позволит перегрузить репозиторий проекта и даст информацию о том, сколько раз использовался компилятор.Спасибо за все замечательные ответы до сих пор!

Answer 1

По моему мнению, внедрение автоматизированного сервера сборки было бы самым чистым решением для того, чего вы пытаетесь достичь. С дополнительным преимуществом ... постоянная интеграция! (Я коснусь CI чуть позже).

Существует множество инструментов для использования. @Clifford уже упоминал CMake. Но некоторые другие:

• Хадсон (с открытым исходным кодом)
• CruiseControl (с открытым исходным кодом)
• TeamCity (Коммерческая - но она имеет довольно щедрую бесплатную версию, которая позволяет использовать до 3 агентов сборки и 20 конфигураций сборки. Корпоративная версия TeamCity - это то, что использует моя компания, поэтому мой ответ будет направлен на это то, что я знаю, но концепции, вероятно, будут применяться ко всем инструментам)

Итак, прежде всего я попытаюсь объяснить, что мы делаем, и предложить, как это может работать для вас. Я не предполагаю, что это принятый способ сделать что-то, но он сработал для нас. Как я уже говорил, мы используем TeamCity для нашего сервера сборки. Каждый программный проект добавляется в TeamCity и настраивается конфигурация. Конфигурации сборки сообщают TeamCity, когда создавать, как создавать и где находится репозиторий SCM вашего проекта. Мы используем две разные конфигурации сборки для каждого проекта, одну из которых мы называем «интеграция», которая контролирует репозиторий SCM проекта и запускает инкрементную сборку при обнаружении регистрации. Другая конфигурация, которую мы называем «ночная», запускается в определенное время каждую ночь и выполняет полностью чистую сборку.

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

Таким образом, когда сборка запускается для конкретной конфигурации сборки, сервер извлекает последние файлы из хранилища и отправляет их «агенту сборки», который выполняет сборку с использованием сценария сборки. Мы использовали Rake для сценариев наших сборок и автоматического тестирования, но вы можете использовать все что угодно. Агент сборки может находиться на том же ПК, что и сервер, но в нашем случае у нас есть отдельный ПК, потому что наш сервер сборки расположен в центре с отделом ИКТ, в то время как нам нужно, чтобы наш агент сборки физически находился в моей команде (для автоматической целевое тестирование). Таким образом, наборы инструментов, которые вы используете, установлены в вашем агенте сборки.

Как это может сработать для вас?

Допустим, вы работаете в TidyDog и у вас есть два проекта:

1. «PoopScoop» основан на цели PIC18F, скомпилированной с использованием компилятора C18, чья магистраль расположена в SCM по адресу //PoopScoop/TRUNK/
2. "PoopBag" основан на цели ColdFire, скомпилированной с GCC, ствол которой расположен в //PoopBag/TRUNK/

Компиляторы, необходимые для сборки всех проектов, установлены на вашем агенте сборки (назовем его TidyDogBuilder). Будет ли это тот же компьютер, на котором работает сервер сборки, или отдельный блок, зависит от вашей ситуации. Каждый проект имеет свой собственный скрипт сборки (например, //PoopScoop/Rakefile.rb и //PoopBag/Rakefile.rb), который обрабатывает зависимости исходного файла и вызывает соответствующие компиляторы. Например, вы можете перейти к // PoopScoop / в командной строке, ввести rake, и скрипт сборки позаботится о компиляции проекта PoopScoop в командной строке.

Затем вы настраиваете свои конфигурации сборки на сервере сборки.Конфигурация сборки для PoopScoop, например, будет указывать, какой инструмент SCM вы используете, и расположение хранилища (например, //PoopScoop/TRUNK/), указывать, какой агент сборки использовать (например, TidyDogBuilder), указывать, где найти подходящий сценарий сборки, и любую необходимую команду.использовать (например, //PoopScoop/Rakefile.rb, вызванный с rake incremental:build) и указать, какое событие вызывает сборку (например, Обнаружение регистрации на //PoopScoop/TRUNK/).Таким образом, идея заключается в том, что если кто-то отправит изменение в //PoopScoop/TRUNK/Source/Scooper.c, сервер сборки обнаружит это изменение, извлечет последние версии исходных файлов из хранилища и отправит их агенту сборки для компиляции с использованием сценария сборки и в концепо электронной почте каждому разработчику, у которого есть изменения в сборке с результатом сборки.

Если ваши проекты должны быть скомпилированы для нескольких целей, вы просто измените сценарий сборки проекта, чтобы справиться с этим (например, у вас могут быть такие команды, как * 1055).* или rake build:Coldfire) и настройте отдельную конфигурацию сборки на сервере сборки для каждой цели.

Непрерывная интеграция

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

Заключительные мысли

• Разработчики, не имеющие всех установок инструментальных цепочек, будут в некоторой степени зависеть от того, какую работу они выполняют чаще всего.Если бы это был я и моя работа была в основном на низком уровне, много взаимодействуя с аппаратным обеспечением, то отсутствие компиляторов на моей рабочей станции раздражало бы меня.С другой стороны, если я в основном работаю на уровне приложений и могу заглушить аппаратные зависимости, это может быть не такой проблемой.
• В TeamCity есть плагин для Eclipse с довольно интересной функцией.Вы можете делать личные сборки, что означает, что разработчики могут запускать сборку ожидающих изменений для любой заданной конфигурации сборки.Это означает, что разработчик инициирует сборку предварительно переданного кода на сервере сборки без необходимости фактически передавать свой код в SCM.Мы используем это для пробных изменений по сравнению с нашими текущими модульными тестами и статическим анализом, поскольку наши дорогие инструменты тестирования устанавливаются только на агенте сборки.
• Что касается доступа к артефактам сборки, когда «в дороге» я согласен, что-то вродеVPN в вашей интрасети, вероятно, самый простой вариант.

Answer 2

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

В моем случае я использую утилиту «Unison» для зеркального отображения раздела моего домашнего каталога на моем ноутбуке для разработчиков в разделе домашнего каталога на серверах сборки. С точки зрения программиста, Unison - это в основном оболочка для rsync с сохраненным набором контрольных сумм, чтобы определить, были ли изменены файлы на обоих концах соединения. Это использует это, чтобы сделать двунаправленную синхронизацию; любые модификации, которые я делаю локально, передаются на удаленный конец, и наоборот. Обычный режим работы - запросить подтверждение всех переводов; Вы можете отключить это, но я считаю, что это удобно для проверки того, что я изменил то, что, как мне кажется, я изменил.

Итак, мой обычный рабочий процесс:

• Редактируйте файлы локально на моей машине для разработки.
• Запустите "unison", чтобы синхронизировать эти изменения с сервером сборки.
• В ssh-соединении с сервером сборки запустите компилятор.
• Также в этом соединении ssh запустите программу, создав выходной файл. (Это, конечно, немного отличается от вашей ситуации.)
• Запустите "unison" еще раз, чтобы синхронизировать измененный выходной файл обратно на мою машину разработки. (Вы будете синхронизировать скомпилированную программу здесь.)
• Посмотрите результаты вывода на моей машине для разработки.

Это не так быстро, как цикл edit-compile-run на локальном компьютере, но я считаю, что он все еще достаточно быстр, чтобы не раздражать. И это гораздо менее тяжело, чем использование контроля источника в качестве посредника; вам не нужно проверять каждое внесенное вами изменение и записывать его для потомков.

Кроме того, Unison имеет преимущество в том, что он довольно хорошо работает на разных платформах; вы можете использовать его в Windows (проще всего с Cygwin, хотя это и не требуется), и он может либо туннелировать через SSH-соединение, если вы запускаете SSH-сервер на вашем компьютере с Windows, запускаете свою собственную службу соединений на сервере сборки, либо просто используйте общий файловый ресурс Windows и рассматривайте сервер сборки как «локальный» файл. (Или вы можете поместить файлы на стороне сервера в общий ресурс Samba на базе Linux в ферме серверов и смонтировать его на виртуальных машинах сборки Windows; это может быть проще, чем наличие «локальных» файлов в виртуальных машинах.)

Редактировать: На самом деле, это своего рода модификация варианта 2 в дискуссии littleadv о передаче файлов; он занимает место редактирования файлов непосредственно на сервере через общие папки Samba / NFS. И он работает достаточно хорошо параллельно с этим - я считаю, что локальный кеш файлов идеален и позволяет избежать проблем с задержкой сети при удаленной работе, но другие инженеры в моей компании предпочитают что-то вроде sshfs (и, конечно, -сайт с использованием Samba или NFS - это нормально). Все это дает один и тот же результат с точки зрения сервера сборки.

Answer 3

Я не уверен, что понимаю, что вы имеете в виду, но я постараюсь ответить на вопрос, который мне кажется: -)

Прежде всего, вы говорите о кросс-компиляторах,право?Вы компилируете в одной системе код для запуска в другой системе.

Во-вторых, вы ищете «плавающую» модель лицензии, вместо того, чтобы иметь выделенную лицензию компилятора на разработчика.

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

Эти проблемы не одинаковы.Я постараюсь охватить их:

1. Кросс-компиляторы - некоторые бесплатны, некоторые лицензированы.Некоторые поставляются с IDE, некоторые - просто компиляторы командной строки, которые могут быть интегрированы в Eclipse / VS / SlickEdit / vi / whatelse.Я не знаю, какой из них вы используете, поэтому давайте посмотрим на Tornado (компилятор VxWorks).Он имеет собственную ужасную среду разработки, но может быть интегрирован в другие (я использовал SlickEdit напрямую с файлами проекта, работает как шарм).Компилятор Tornado требует лицензии и имеет несколько различных моделей, поэтому мы рассмотрим его в следующих двух пунктах.

2. Плавающие лицензии.Например, Tornado может поставляться либо с одной лицензией на модель установки, либо с плавающей лицензией, которая будет распределять лицензии по запросу.Если вы используете машину для сборки - вам понадобится либо одна лицензия (в этом случае вы можете запускать только один экземпляр за раз, что противоречит цели), либо плавающая лицензия для запуска нескольких экземпляров одновременно.Некоторым кросс-компиляторам / библиотекам вообще не требуются лицензии (например, различные разновидности GCC).

3. Сборочная машина - я испытал использование VxWorks Tornado в качестве выделенного компилятора на моемПК, а также для установки на сборочной машине.

Для сборочной машины необходим способ передачи кода для сборки.Это проблема №2 для вас:

2) Как / когда передать исходный код на сервер для сборки.

Совместное использование по сети неХорошая идея, так как задержка в сети сделает время компиляции невыносимым.Вместо этого выполните одно из следующих действий:

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

2. Все извлеченные файлы разработчика непосредственно на машине для сборки (большая система UNIX с большим объемом памяти), и каждый разработчик будет редактировать файлы, используя общий сетевой ресурс (SAMBA или NFS), который в локальной сети компании объемом 1 ГБ, и скомпилируется локально на сборочном компьютере.Некоторые редактируют напрямую в системе Unix, используя версию Tornado IDE vi / emacs / Unix, которую я ненавидел.Это также решает вашу проблему # 1:

1) Работа в сети с виртуальной машиной Windows.

(Это не обязательно должно бытьВиртуальная машина Windows, Linux тоже может работать, если у вас есть кросс-компилятор из Linux во встроенную систему).

Надеюсь, это поможет.

Answer 4

Похоже, что вы пытаетесь сделать это " распределенная сборка ", где есть только один сервер сборки.Это может быть возможно с чем-то вроде CMake .Однако, хотя это может «экономить» ваше использование лицензий компилятора, для многих цепочек инструментов однопользовательская лицензия также (или в некоторых случаях исключительно) применима к отладчику;это может быть не особенно полезно, если ваши разработчики не могут отлаживать и тестировать свой код.

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

Самодельное решение заключается в создании собственного приложения TCP / IP, которое принимает команды сборкии файлы, выполняет локальный компилятор или компоновщик и возвращает результаты (журнал компоновки, и / или объектный файл и т. д.).

Возможно, можно полностью избежать этой проблемы, переместив всю разработку в открытый исходный код.инструменты, такие как GCC или SDCC;это будет зависеть от того, какие цели вам нужно поддерживать.

Answer 5

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