CS>Нужно собирать мой Sciter для Raspberry Pi...
CS>Насколько я понимаю это надо делать true Linux way — собирать его на target устройстве.
Обычный способ сборки програм для подобного рода плат это кросс-компиляция.
Сборка на устройстве это может быть стресс-тест для проверки что ты ядро правильно
портировал или еще какой надобности, но использовать это для разработки
CS>Альтернативно можно попробовать cross-compiling, но насколько я понимаю это работает только для простых случаев. Или я ошибаюсь?
С чего вдруг, почитайте про openembbed/yocta/buildroot всю систему целиком собирают
кросс-компиляцией.
CS>Поэтому вопрос по Raspberry Pi dev device, какой он должен быть, например SSD нужен или нет? CS>Вообще у кого есть практический опыт разработки под Raspberry Pi или чего-то аналогичного, как это правильно делать?
Raspberry Pi dev device это современный amd64 компьютер с кучей ядер, памяти и ssd диском.
CS>Поэтому вопрос по Raspberry Pi dev device, какой он должен быть, например SSD нужен или нет?
Хм, там по моему, интерфейс для накопителей отсутствует вообще. Флешка, и всё. У меня правда RPI2, я и на самом деле не добрался пока с ней поковыряться, один раз запустил и отложил
CS>Вообще у кого есть практический опыт разработки под Raspberry Pi или чего-то аналогичного, как это правильно делать?
Под RPI ничего не писал, но вообще писал кросс-платформу для виндов/линоксов/бсд. В основном все делал под виндой, отлаживал платформозависимые части используя CodeBlocks, проект был без куте и прочего.
Еще был проект под какую-то железяку на арме, нормально всё писалось под виндой, тулчайн был code sourcery gcc или как-то так, он вроде загнулся, но не суть, их других есть. Писалось под виндой, отлаживалось в qemu arm linux, финальные тесты на шелезяке прогонялись
Ничего особенного.
А RPI — это обычный arm-linux, там из всех особенностей только порты GPIO, и всё
Здравствуйте, c-smile, Вы писали:
CS>Вообще у кого есть практический опыт разработки под Raspberry Pi или чего-то аналогичного, как это правильно делать?
Я обычно разрабатываю и отлаживаю программу на большом компьютере,
и только в самом конце собираю на Raspberry Pi.
Собираю на самом устройстве без всяких кросс-компиляций.
Для этого нужно установить gcc и девелоперские библиотеки.
Наверное если часто этим заниматься, можно дырку во флешке протереть.
Я пока не протёр.
Здравствуйте, c-smile, Вы писали:
CS>Вообще у кого есть практический опыт разработки под Raspberry Pi или чего-то аналогичного, как это правильно делать?
Собираю на большом компьютере свои программы для Raspberry. Потому что: (1) их приходится пересобирать часто, после каждой правки, (2) скрипты сборки сам писал, и (3) они не тянут 100500 зависимостей от библиотек. И ядро, потому что больно большое и у него со скриптами сборки точно всё в порядке.
Опенсорсные вещи, которые надо пересобрать, что-то подкрутив, собираю на самой Raspberry. Потому что кросс-компиляция оно на словах хорошо, а на деле не очень.
Raspberry Pi dev device это просто третья Raspberry с радиаторами и не самой дешевой microSD. SSD не добавит скорости, упрётся в USB 2.0.
PS: не связывайся с убунтами и прочими левыми дистрибутивами, которые якобы работают на Raspberry. Штатный Raspbian твоё всё.
Здравствуйте, alpha21264, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
CS>>Вообще у кого есть практический опыт разработки под Raspberry Pi или чего-то аналогичного, как это правильно делать?
A>Я обычно разрабатываю и отлаживаю программу на большом компьютере, A>и только в самом конце собираю на Raspberry Pi.
A>Собираю на самом устройстве без всяких кросс-компиляций. A>Для этого нужно установить gcc и девелоперские библиотеки. A>Наверное если часто этим заниматься, можно дырку во флешке протереть. A>Я пока не протёр.
Здравствуйте, /aka/, Вы писали:
A>Собираю на большом компьютере свои программы для Raspberry. Потому что: (1) их приходится пересобирать часто, после каждой правки, (2) скрипты сборки сам писал, и (3) они не тянут 100500 зависимостей от библиотек. И ядро, потому что больно большое и у него со скриптами сборки точно всё в порядке.
Что то написанное на C на малинке собирается в сравнимое с интеловским хостом, на котором 12 Гб ОЗУ и несколько гигагерцный проц.
Вот Java и все JVM`ное великое шаманство есть.
A>Опенсорсные вещи, которые надо пересобрать, что-то подкрутив, собираю на самой Raspberry. Потому что кросс-компиляция оно на словах хорошо, а на деле не очень.
ИМХО кросс-компиляция и есть трувей, ибо позволяет не заморачиваться с тем, что у тебя на целевой системе и тем, что у тебя на хосте.
Банально, тот же плугин к Vim — YouCompleteMe на хосте собирается влет, а на малинке собирается вдамп
A>Raspberry Pi dev device это просто третья Raspberry с радиаторами и не самой дешевой microSD. SSD не добавит скорости, упрётся в USB 2.0.
A>PS: не связывайся с убунтами и прочими левыми дистрибутивами, которые якобы работают на Raspberry. Штатный Raspbian твоё всё.
Распбиан разве не тот же Дебиан с добавленными репозиториями для малинковских дров с отличными от других лицензиями?
Здравствуйте, c-smile, Вы писали:
CS>Поэтому вопрос по Raspberry Pi dev device, какой он должен быть, например SSD нужен или нет?
Любой, лучше Pi3 CS>Вообще у кого есть практический опыт разработки под Raspberry Pi или чего-то аналогичного, как это правильно делать?
Есть два способа:
1. На девайсе. Тут особо проблем нет.
2. Кросскомпильнуть под Raspbian с x86 на arm.
Для кросс компиляции есть два способа:
1 настроить переменные окружения, выставить разные СС, PKGCONFIG и т.п., 2 написать на CMAKE скрипт который будет настраивать всё для тебя. В любом случае будут заморочки с путями к правильным сорцам и правильным либам, правильным pkgconfig файлам и т.п.
Учти, все советы по кросскомпилированию в интернете походят для несложных проектов, что-то комплексное придётся компилировать через боль.
P.S. Если хочешь, можешь мне на на мыло написать, я поделюсь парой хинтов как упростить себе жизнь со кросс-сбркой.
Здравствуйте, Kernan, Вы писали:
K>Есть два способа: K>1. На девайсе. Тут особо проблем нет.
Кроме объема памяти. Тут банально плагин не собрать youcompleteme, дампит по причине нехватки памяти.
K>2. Кросскомпильнуть под Raspbian с x86 на arm. K>Для кросс компиляции есть два способа: K>1 настроить переменные окружения, выставить разные СС, PKGCONFIG и т.п., 2 написать на CMAKE скрипт который будет настраивать всё для тебя. В любом случае будут заморочки с путями к правильным сорцам и правильным либам, правильным pkgconfig файлам и т.п. K>Учти, все советы по кросскомпилированию в интернете походят для несложных проектов, что-то комплексное придётся компилировать через боль.
Можно и ручками настраивать, но ведь все украдено до нас.
Можно использовать дебиановский образ в чруте, можно использовать crosstool-ng для генерации тулчейна, можно с помощью buildroot собрать свой образ под нужную плату. Уж малинка и buildroot`ом и yocto`й поддерживается без бубна. В buildroot даже для somlabs`овского i.mx6ull модуля можно образ собрать.
Так что сложности кроскомпиляции несколько преувеличены, ИМХО.
Хотя, конечно, я может с такими задачами не сталкивался, что собираются через кровь, боль и маты.
Подкиньте плиз примерчики, не корысти срача ради, а чисто из любопытства
Здравствуйте, Lucky Cat, Вы писали:
LC>Распбиан разве не тот же Дебиан с добавленными репозиториями для малинковских дров с отличными от других лицензиями?
Официального Дебиана для Малины нет. Нельзя скачать официальный образ с debian.org, только частные поделки. Есть образогенератор rpi23-gen-image, которым можно сделать свой образ Дебиана для Малины на другой машине с Дебианом, но количество необходимых допилов в получившейся системе меня утомило.
А Raspbian работает из коробки. Репозитории у них свои, то есть "тот же Дебиан" они пересобирают и напильником обтачивают.
Здравствуйте, c-smile, Вы писали:
CS>Вообще у кого есть практический опыт разработки под Raspberry Pi или чего-то аналогичного, как это правильно делать?
Здравствуйте, Lucky Cat, Вы писали:
LC>Можно использовать дебиановский образ в чруте, можно использовать crosstool-ng для генерации тулчейна, можно с помощью buildroot собрать свой образ под нужную плату. Уж малинка и buildroot`ом и yocto`й поддерживается без бубна. В buildroot даже для somlabs`овского i.mx6ull модуля можно образ собрать.
Ок, ок. Какой из способов использовал лично ты на RPi? А то я много видел вот таких вот рекомендаций, только потом выяснялось, что рекомендатели ни разу их не использовали на конкретном таргете. LC>Так что сложности кроскомпиляции несколько преувеличены, ИМХО. LC>Хотя, конечно, я может с такими задачами не сталкивался, что собираются через кровь, боль и маты.
Для hello world, да, что-то сложнее придётся собирать через боль. Свежие OPS либы только через танцы с бубном.
Здравствуйте, Kernan, Вы писали:
K>1. На девайсе. Тут особо проблем нет.
Вопрос чисто из любопытства, сборку в докер контейнере не пробовали? https://hub.docker.com/r/raspbian/jessie/
Здравствуйте, c-smile, Вы писали:
CS>Вообще у кого есть практический опыт разработки под Raspberry Pi или чего-то аналогичного, как это правильно делать?
Я таким занимался. Пробовал все методы. "Правильный" зависит от задачи. Если один раз собрать и забыть, то можно прямо на целевой платформе, если же нужна разработка с отладкой, оптимизацией и внесение правок, то кросс компиляция будет быстрее. Мне потребовался месяц, чтобы перенести проект на ARM, но у меня куча библиотек, типа Boost, Qt, websocket, многопоточность, работа с USB и serial портами...
В конечном итоге пришёл к тому, что написал руками универсальные Makefile'ы для кросс компиляции, которые в зависимости от указанной целевой платформы выбирают те или иные опции из подключаемых файлов.
Получилось так: под виндой запускается virtual box, в котором устанавливается и настраивается система под конкретную платформу, после чего в эту систему расшаривается виндовый каталог с исходниками и прямо в этом каталоге запускается компиляция.
Удобство в том, что под каждую целевую платформу мы имеем специальную виртуальную машину с полностью настроенной cross-tools цепочкой. Такую виртуальную машину можно забекапить, перенести на другой компьютер, что в условиях командной работы экономит много времени.
Здравствуйте, B0FEE664, Вы писали:
BFE>Получилось так: под виндой запускается virtual box, в котором устанавливается и настраивается система под конкретную платформу, после чего в эту систему расшаривается виндовый каталог с исходниками и прямо в этом каталоге запускается компиляция.
Не ясно что имеется ввиду. virtual box позволяет запускать i86/x64 системы. Но тут же ARM архитектура. Или я чего не понял?
Здравствуйте, c-smile, Вы писали:
BFE>>Получилось так: под виндой запускается virtual box, в котором устанавливается и настраивается система под конкретную платформу, после чего в эту систему расшаривается виндовый каталог с исходниками и прямо в этом каталоге запускается компиляция.
CS>Не ясно что имеется ввиду. virtual box позволяет запускать i86/x64 системы. Но тут же ARM архитектура. Или я чего не понял?
Да, это я не ясно выразился. Я использую кросс компиляцию, т.е. на архитектуре i86/x64 создаю бинарник, который запускается на ARM платформе. Процессоры ARM различаются по своей архитектуре. Для каждой модели процессора существует своя процедура кросс компиляции, которая, как правило, обеспечивается стараниями производителя процессора. Установить и настроить на одной системе несколько инструментов для кросс компиляции можно, но сложно и их легко перепутать, они могут конфликтовать. В системе установленной в virtual box я инсталлирую и настраиваю инструменты необходимые для кросс компиляции под конкретную систему работающую на конкретной модели ARM. Т.е. если на сайте поставщика системы написано, что они рекомендуют использовать, скажем, Ubuntu такой-то версии, то мы берём эту Ubuntu указанной версии и устанавливаем её в Virtual Box. После чего скачивает и настраиваем рекомендуемые для кросс компиляции инструменты в этой отдельной виртуальной машине. В этой же виртуальной машине инсталлируем и компилируем с помощью установленных инструментов компиляции библиотеки, которые нам нужны для наших программ. После завершения этих процедур можно компилировать собственные исходники. Вот как-то так.
c-smile:
CS>Вообще у кого есть практический опыт разработки под Raspberry Pi или чего-то аналогичного, как это правильно делать?
Специально для малины профессионально не разрабатывал, но в свое время много возился с настройками.
Кроме перечисленного выше в ветке, могу подсказать еще два способа:
1. Foreign debootstrap. В некотором каталоге на хосте x86 (или x64) устанавливается дистрибутив линукса ARM, совместимый с малиной.
Бинарники работают через qemu-user. Способ по затратам сравним со сборкой кросс-компилятора, но иногда может быть удобнее.
2. Запустить эмулятор малины через qemu-system, и из него собрать. ИМХО, проще, чем с проводами возиться.
Модератор-националист Kerk преследует оппонентов по политическим мотивам.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, Lucky Cat, Вы писали:
LC>>Можно использовать дебиановский образ в чруте, можно использовать crosstool-ng для генерации тулчейна, можно с помощью buildroot собрать свой образ под нужную плату. Уж малинка и buildroot`ом и yocto`й поддерживается без бубна. В buildroot даже для somlabs`овского i.mx6ull модуля можно образ собрать. K>Ок, ок. Какой из способов использовал лично ты на RPi? А то я много видел вот таких вот рекомендаций, только потом выяснялось, что рекомендатели ни разу их не использовали на конкретном таргете.
Конкретно для RPi3 buildroot, yocto и QEMU/debootstrap использовал лично я.
Так что не надо патетики. Может я и не запускаю коллайдеры на малинке, но кросскомпиляцию под свои задачи использовал.
Без боли и мата.
LC>>Так что сложности кроскомпиляции несколько преувеличены, ИМХО. LC>>Хотя, конечно, я может с такими задачами не сталкивался, что собираются через кровь, боль и маты. K>Для hello world, да, что-то сложнее придётся собирать через боль. Свежие OPS либы только через танцы с бубном.
Если что то делается через боль,то может не тем способом.
А некоторые вещи кроме как кросс-компиляцией не соберете.
