Как установить и использовать компиляторы для embedded C на внешнем сервере?
Короткий Вопрос
Существует ли принятый способ запуска компиляторов / компоновщиков для встроенных программных проектов на удаленном сервере и по-прежнему иметь возможность программировать и отлаживать программное обеспечение на локальном компьютере.
Примечание Я знаю, что каждая IDE будет отличаться, поэтому мне нужно определить рабочий поток для выполнения этой задачи, предполагая, что IDE можно запустить с помощью .о./файлы elf, построенные с удаленного сервера.
зоны Концерн
1) Подключение к виртуальной машине Windows.
2) как / когда передать исходный код на сервер для сборки.
фон
Каждое семейство микропроцессоров, с которыми работает наша команда, требует собственного компилятора, IDE и программиста. Это, сверхурочные, создает много трудностей для преодоления.
1) каждый разработчик требует своей собственной, часто дорогой, лицензии.
2) подобрать проект для запуска другого разработчика требуется дополнительная осторожность, чтобы убедиться, что все настройки компилятора одинаковы.
3) Для поддержки устаревшего программного обеспечения могут потребоваться старые компиляторы, конфликтующие с установленным компилятором.
... список можно продолжать и продолжать.
Edit: 7-10-2011 1: 30 PM CST
1) компиляторы я говорю о действительно кросскомпиляторы
2) краткий список семейств процессоров, которые эта система идеально поддерживает: Motorola Coldfire, PIC и STM8.
3) наш компилятор Coldfire является вариантом GCC, но мы должны поддерживать несколько его версий. Все остальные компиляторы используют целевой компилятор, который не предоставляет плавающую лицензию.
4) чтобы обратиться к littleadv, я хотел бы выполнить внешний сервер сборки.
5) в настоящее время мы используем комбинацию SVN и GIT, размещенных в онлайн-репозитории для управления версиями. Это на самом деле, как я думал, я буду передавать файлы в сборку сервер.
6) мы застряли с Windows, для большинства компиляторов.
теперь я считаю, что направление движения-это внешний сервер сборки. Есть еще несколько препятствий. Я предполагаю, что нам придется перенести исходные файлы на сервер через программное обеспечение управления версиями. Видя, как несколько строк продуктов требуют доступа к одним и тем же компиляторам, наличие экземпляра для каждого проекта не кажется практичным.
имеет ли смысл создавать репозиторий для каждого компилятора, который будет включать папки для сборки, источника, включения, вывода и т. д... затем скрипты на стороне пользователей, которые заботятся о перемещении файлов, формируют файловую структуру IDE в требуемую структуру для компилятора? Этот подход позволит сохранить репозиторий проекта от избиения и дать с тех пор, сколько раз использовался компилятор. Спасибо за все ответы до сих пор!
5 ответов
на мой взгляд, автоматизированная сборка сервера будет наилучшим решением для того, что вы пытаетесь достичь. С дополнительным преимуществом...непрерывная интеграция! (Я коснусь CI немного позже).
есть много инструментов там, чтобы использовать. @Clifford уже упоминал CMake. Но некоторые другие:
- Гудзон (С Открытым Исходным Кодом)
- CruiseControl (открытое Источник)
- TeamCity (коммерческий-но он имеет довольно щедрую бесплатную версию, которая позволяет до 3 агентов сборки и 20 конфигураций сборки. Корпоративная версия TeamCity-это то, что использует моя компания, поэтому мой ответ будет ориентирован на это, поскольку это то, что я знаю, но концепции, вероятно, будут применяться через несколько инструментов)
кстати, просто краткое замечание относительно SCM. Чтобы это работало максимально чисто, я думаю, что SCM для каждого проекта должен использоваться в стабильной топологии магистрали. Если все ваши разработчики работают из своих собственных ветвей, вам, вероятно, понадобятся отдельные конфигурации сборки для каждого разработчика, которые, я думаю, будут излишне грязными. Мы настройте наш сервер сборки с собственной учетной записью пользователя SCM, но с доступом только для чтения.
поэтому, когда сборка запускается для определенной конфигурации сборки, сервер захватывает последние файлы из репозитория и отправляет их "агенту сборки", который выполняет сборку с помощью сценария сборки. Мы использовали грабли для сценария наших сборок и автоматического тестирования, но вы можете использовать все, что угодно. Агент сборки может быть на том же ПК, что и сервер, но в нашем случае у нас есть отдельный ПК, потому что наш сервер сборки централизованно расположен с отделом ИКТ, тогда как нам нужно, чтобы наш агент сборки физически находился с моей командой (для автоматизированного тестирования на цели). Таким образом, используемые цепочки инструментов устанавливаются в Агенте сборки.
как это может работать для вас?
допустим, вы работаете на TidyDog, и у вас есть два проекта на ходу:
- "PoopScoop" основан на цели PIC18F, скомпилированной с помощью компилятора C18 багажник, расположенный в вашем SCM at
//PoopScoop/TRUNK/ - "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 сервер сборки обнаруживает это изменение, захватывает последние версии исходных файлов из репозитория и отправляет их агенту сборки для компиляции с помощью сценария сборки и в конце электронной почты каждый разработчик, который имеет изменение в сборке с результатом сборки.
если ваши проекты должны быть скомпилированы для нескольких целей, вы просто измените сценарий сборки проекта, чтобы справиться с этим (например, у вас могут быть такие команды, как rake build:PIC18 или rake build:Coldfire) и настройте отдельную конфигурацию сборки на сервере сборки для каждой цели.
Непрерывная Интеграция
таким образом, с этой системой вы получаете непрерывную интеграцию и запуск. Измените сценарии сборки на запустите модульные тесты, а также скомпилируйте проект, и вы можете выполнить модульное тестирование автоматически после каждого изменения. Мотивом для этого является попытка как можно раньше подобрать проблемы, поскольку вы развиваетесь, а не удивляетесь во время проверочной деятельности.
Закрытие Мысли
- разработчики, не имеющие всех установок toolchain, будут несколько зависеть от того, какую работу они делают чаще всего. Если бы это была я и моя работа, быть в основном низкоуровневым, много взаимодействовать с оборудованием, не имея компиляторов на моей рабочей станции, будет раздражать bejeezes из меня. Если, с другой стороны, я в основном работал на уровне приложений и мог заглушить аппаратные зависимости, это не может быть такой проблемой.
- TeamCity имеет плагин для Eclipse с довольно крутой функцией. Вы можете выполнять личные сборки, что означает, что разработчики могут запускать сборку ожидающего списка изменений для любой заданной конфигурации сборки. Это средство что разработчик инициирует сборку предварительного кода на сервере сборки без необходимости фактически отправлять свой код в SCM. Мы используем это для пробных изменений против наших текущих модульных тестов и статического анализа, поскольку наши дорогие инструменты тестирования установлены только на агенте сборки.
- что касается доступа к артефактам сборки, когда "на дороге" я согласен, что-то вроде VPN в вашей интрасети, вероятно, самый простой вариант.
одна часть вашего вопроса, которая не была рассмотрена в других ответах (по крайней мере, на момент, когда я пишу это), - это как перенести файлы на сервер сборки. Я могу предоставить некоторый опыт в этом вопросе, поскольку мой собственный процесс развития достаточно близок к этой части вашей ситуации.
в моем случае я использую утилиту "Unison", чтобы отразить раздел моего домашнего каталога на моем ноутбуке разработки в раздел домашнего каталога на серверах сборки. С точки зрения программиста, Unison-это в основном оболочка вокруг rsync, с сохраненным набором контрольных сумм, чтобы определить, были ли изменены файлы на любом конце соединения. Он использует это для двунаправленной синхронизации; любые изменения, которые я делаю локально, передаются на удаленный конец и наоборот. Обычный режим работы-запросить подтверждение всех переводов; вы можете отключить его, но я нахожу его удобным в качестве проверки, чтобы убедиться, что я изменил то, что думаю Я изменился.
Итак, мой обычный рабочий процесс:
- редактировать файлы локально на моей машине разработки.
- запустите "unison", чтобы синхронизировать эти изменения до сервера сборки.
- в ssh-соединении с сервером сборки запустите компилятор.
- также в этом ssh-соединении запустите программу, создав выходной файл. (Это, конечно, немного отличается от вашей ситуации.)
- снова запустите "unison", чтобы синхронизировать измененные выходной файл обратно на мою машину разработки. (Здесь вы синхронизируете скомпилированную программу.)
- смотреть на результат на моей машине разработки.
Это не так быстро, как цикл edit-compile-run на локальной машине, но я нахожу, что он все еще достаточно быстр, чтобы не раздражать. И это гораздо менее тяжелый вес, чем использование системы управления версиями в качестве посредника; вам не нужно проверять каждое редактирование и записывать его для потомство.
также, унисон работает довольно хорошо на разных платформах; вы можете использовать его на Windows (Самый простой с использованием Cygwin, хотя это не обязательно), и он может либо туннель через SSH-подключение при запуске SSH-сервер на компьютере Windows, запустить свой собственный подключение услуги на билд-сервере, или просто использовать Windows файловый и обработайте построить сервер как "местный" файл. (Или вы можете поместить файлы на стороне сервера в общий ресурс Samba на основе Linux на сервере ферма и смонтировать ее на Windows build VMs; это может быть проще, чем иметь "локальные" файлы в VMs.)
Edit: на самом деле, это своего рода модификация варианта 2 в обсуждении littleadv о передаче файлов; он занимает место редактирования файлов непосредственно на сервере через Samba/NFS shares. И он работает достаточно хорошо параллельно с этим-я считаю, что наличие локального кэша файлов идеально и позволяет избежать проблем с сетевым лагом при удаленной работе, но другие инженеры в моей компании предпочитают что-то вроде sshfs (и, конечно, на месте с использованием Samba или NFS хорошо). Все это дает один и тот же результат с точки зрения сервера сборки.
Я не уверен, что понимаю, что вы имеете в виду, но я попытаюсь ответить на то, что я думаю, что вопрос :-)
прежде всего, вы говорите о кросс-компиляторах, верно? Вы компилируете в одной системе код для запуска в другой системе.
во-вторых, вы ищете "плавающую" модель лицензии, а не специальную лицензию компилятора для каждого разработчика.
В-третьих, вы хотите иметь машину сборки, где каждый будет компилироваться, а не каждый разработчик компилирует на собственной машине.
эти проблемы не то же самое. Я постараюсь их прикрыть:--1-->
Кросс-компиляторы - некоторые из них бесплатны, некоторые имеют лицензию. Некоторые поставляются с IDE, некоторые-просто компиляторы командной строки, которые могут быть интегрированы в Eclipse/VS/SlickEdit/vi/whatelse. Я не знаю, какой из них вы используете, поэтому давайте посмотрим на Tornado (компилятор VxWorks). Он имеет свою собственную ужасную IDE, но может быть интегрирован в другие (я использовал SlickEdit с это файлы проекта напрямую, работает как шарм). Компилятор Tornado требует лицензии и имеет несколько разных моделей, поэтому мы рассмотрим его для следующих двух точек.
плавающие лицензии. Торнадо, например, может поставляться либо с одной лицензией на модель установки, либо с плавающей лицензией, которая будет выделять лицензии на запрос. Если вы используете машину сборки - вам понадобится либо одна лицензия (в этом случае вы можете запускать только один экземпляр за раз, который побеждает цель), или плавающая лицензия для запуска нескольких экземпляров одновременно. Некоторые кросс-компиляторы / библиотеки вообще не требуют лицензий (например, различные варианты GCC).
Build machine-я испытал использование VxWorks Tornado как в качестве выделенного компилятора на моем ПК, так и в качестве установки build-machine.
для машины сборки вам нужен способ передать код для сборки. Это проблема #2 для вас:
2) как / когда источник передачи код на сервер для сборки.
совместное использование по сети не является хорошей идеей, поскольку задержка сети сделает время компиляции невыносимым. Вместо этого выполните одно из следующих действий:
установите исходный элемент управления на машине сборки, попросите разработчиков передать код через исходный элемент управления. Это создает риск разрушения системы управления версиями, поэтому мы сделали следующее это:
все проверенные разработчиком файлы на машине сборки напрямую (большая система UNIX с большим количеством хранилища), и каждый разработчик будет редактировать файлы, используя сетевой ресурс (SAMBA или NFS), который на 1GB company LAN был в порядке, и компилировать локально на машине сборки. Некоторые будут редактировать непосредственно в системе Unix, используя vi/emacs / Unix версию Tornado IDE, которую я ненавидел. Это также отвечает на вашу проблему #1:
1) Подключение к виртуальной Windows машина.
(Это не должна быть виртуальная машина Windows, Linux может работать тоже, если у вас есть кросс-компилятор от Linux до вашей встроенной системы).
надеюсь, это поможет.
Я не эксперт здесь, но можно ли создать виртуальную машину для каждой целевой среды. Затем разработчик может запустить образ виртуальной машины на локальном компьютере.
кажется, что то, что вы пытаетесь сделать, это"распределенной сборки " где есть только один сервер сборки. Это возможно с чем-то вроде CMake. Однако, хотя это может "сэкономить" ваше использование лицензий компилятора, для многих цепочек инструментов лицензия одного пользователя также (или в некоторых случаях исключительно) применяется к отладчику; это может быть не особенно полезно, если ваши разработчики не могут отлаживать и тестировать свой код.
одним из решений является возможно, использовать одну машину с необходимыми инструментами разработки и целевым оборудованием и получить доступ к ней с нескольких рабочих станций через удаленный рабочий стол или даже Telnet, если вам нужен только интерфейс командной строки. Удаленный рабочий стол будет разрешать доступ только одному пользователю за раз,но множественный одновременный доступ, вероятно, будет противоречить EULA во многих случаях.
решение DIY заключается в создании собственного приложения TCP / IP, которое принимает команды сборки и файлы, выполняет локальный компилятор или компоновщик и возвращает результаты (журнал сборки, и / или объектный файл и т. д.).
возможно, удастся полностью избежать этой проблемы, переместив все ваши разработки в инструменты с открытым исходным кодом, такие как GCC или SDCC; это будет зависеть от того, какие цели вам нужно поддерживать.