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 либы только через танцы с бубном.
Если что то делается через боль,то может не тем способом.
А некоторые вещи кроме как кросс-компиляцией не соберете.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, c-smile, Вы писали:
CS>>Да медленно, но тем не менее работает. K>Поздравляю. Пробовал кросс-компилить или так и забил на это дело?
Забил. Поленился переводить существующий проект (Code::Blocks) на make.
Code::Blocks на Raspbian заработал поэтому и не дергался особо.
Здравствуйте, Pzz, Вы писали:
A>>и только в самом конце собираю на Raspberry Pi.
Pzz>А зачем ты это вообще делаешь? Чем плох кросс-скомпилированный исполняемый файл?
Тем, что я не хочу трахаться с кросс-компиляцией.
Объяснить тебе какие проблемы вызывает кросс-компиляция?
Здравствуйте, c-smile, Вы писали:
CS>Насколько я понимаю это надо делать true Linux way — собирать его на target устройстве.
В целом это проще всего.
CS>Альтернативно можно попробовать cross-compiling, но насколько я понимаю это работает только для простых случаев. Или я ошибаюсь?
Нет, это работает для любых случаев и в основном так и работают, особенно когда речь идёт о слабых устройствах. Но в случае с распберри — наверное можно и на целевом устройстве всё делать, если у тебя не гугль хром по времени компиляции и требованиям к железу.
CS>Поэтому вопрос по Raspberry Pi dev device, какой он должен быть, например SSD нужен или нет?
Никаких принципиальных отличий от обычного компьютера нет. Чем лучше "железо", тем удобней работать. Естественно SSD сделает работу комфортней. Возможно грузиться придётся с SD-карты, я точно не знаю, умеет ли он грузиться с USB.
CS>Вообще у кого есть практический опыт разработки под Raspberry Pi или чего-то аналогичного, как это правильно делать?
Если речь именно про Raspberry Pi, то это почти обычный дебиан. Для юзерспейса тебе особо ни о чём думать не надо.
А если речь про embedded устройства, там обычно пользуются кросс-компиляцией. Проекты buildroot, yocto из популярных, многие просто своими скриптами сами линукс собирают.
Здравствуйте, Zhendos, Вы писали:
Z>Сборка на устройстве это может быть стресс-тест для проверки что ты ядро правильно Z>портировал или еще какой надобности
Мне вот интересно, есть ли хоть одна надобность, не говоря уже о "еще какой". Единственное, что приходит на ум — отсутствие нормального кросс-компилятора для целевой платформы. Но такое, насколько я знаю, кончилось еще лет двадцать назад.
Здравствуйте, c-smile, Вы писали:
CS>можно попробовать cross-compiling, но насколько я понимаю это работает только для простых случаев.
Какие-либо проблемы с кросс-компиляцией возможны лишь в том случае, когда целевая платформа — мейнстрим, и большинство занимается разработкой непосредственно на ней, а кросс-компилятор для платформы, которая у Вас, сделан "на отъ.ись" (ограниченный, тормозной, глючный и т.п.). Например, если б Вам потребовалось на RPi собрать бинарники для винды.
Если же основная платформа — винда/линукс/макось, а целевая используется в основном во встроенном виде, то собирать надо как раз на основной, кросс-средствами.
Здравствуйте, alpha21264, Вы писали:
Pzz>>А зачем ты это вообще делаешь? Чем плох кросс-скомпилированный исполняемый файл? A>Тем, что я не хочу трахаться с кросс-компиляцией. A>Объяснить тебе какие проблемы вызывает кросс-компиляция?
А объясни. Очень любопытно, как это объяснить тому, кто сам никогда не трахался с кросс-компиляцией. В теории там всё прозрачно, теоретеги нагадят на доску и улетят всем рассказывать, как они тебя уделали на любой пример из жизни ответят, что у тебя руки кривые, а на самом деле всё работает.
Здравствуйте, /aka/, Вы писали:
A>любопытно, как это объяснить тому, кто сам никогда не трахался с кросс-компиляцией.
Особенно любопытно, как это объяснять тем, кто делает софт для микроконтроллеров Intel/PIC/AVR, для которых "нативных" компиляторов не существует в природе.
A>В теории там всё прозрачно
Если на практике непрозрачно, причина может быть только одна — кривая кросс-система. Других причин не бывает.
Здравствуйте, Marty, Вы писали:
CS>>Поэтому вопрос по Raspberry Pi dev device, какой он должен быть, например SSD нужен или нет? M>Хм, там по моему, интерфейс для накопителей отсутствует вообще. Флешка, и всё. У меня правда RPI2, я и на самом деле не добрался пока с ней поковыряться, один раз запустил и отложил
Так оно, но есть исключение. У проца RPi4 есть PCIе шина, но она используется для контроллера USB3. Есть рецепты, как подпаять PCIe слот к PRi4 А бывает RPi4 в виде IO Board + Compute Module, там один слот x1 из коробки.
Здравствуйте, Lucky Cat, Вы писали:
LC>Что то написанное на C на малинке собирается в сравнимое с интеловским хостом, на котором 12 Гб ОЗУ и несколько гигагерцный проц.
Если убрать с хоста 8 Гб ОЗУ, а процу добавить гигагерц, оно соберется как-то иначе?
Здравствуйте, Kernan, Вы писали:
K>все советы по кросскомпилированию в интернете походят для несложных проектов, что-то комплексное придётся компилировать через боль.
Это может означать только то, что средства кросс-компиляции для линукса по определению кривы, и чрезмерно завязаны на локальную среду, чего в них быть не должно. Виндовые средства в этом смысле правильнее, поскольку винда до самых недавних пор активно использовалась лишь на интеловской архитектуре, отчего шансов обнаружить ее на целевой платформе и завязаться на локальную среду практически не было. А то, что линукс уже давно идет практически везде, создает изрядный соблазн делать вместо правильной кросс-компиляции костыльную, отсюда и вся эта боль.
Здравствуйте, B0FEE664, Вы писали:
BFE>Процессоры ARM различаются по своей архитектуре. Для каждой модели процессора существует своя процедура кросс компиляции
Все настолько ужасно, что при смене модели ARM требуется менять процедуру, а не просто ключи у компилятора/линкера? Или это требуется лишь для самых новых моделей, для которых еще не подтянули универсальных кросс-средств?
BFE>Т.е. если на сайте поставщика системы написано, что они рекомендуют использовать, скажем, Ubuntu такой-то версии, то мы берём эту Ubuntu указанной версии
Вот это меня тоже всегда поражало в линуксах — в системах, созданных и продвигаемых под эгидой взаимной совместимости, шаманства от возможной несовместимости наблюдается подозрительно много.
Здравствуйте, Евгений Музыченко, Вы писали:
BFE>>Процессоры ARM различаются по своей архитектуре. Для каждой модели процессора существует своя процедура кросс компиляции ЕМ>Все настолько ужасно, что при смене модели ARM требуется менять процедуру, а не просто ключи у компилятора/линкера? Или это требуется лишь для самых новых моделей, для которых еще не подтянули универсальных кросс-средств?
Прошло 5 лет и сейчас стало намного проще: новые версии gcc хорошо понимают ARM архитектуру и проблем с компиляцией стало существенно меньше. Можно даже из-под винды делать кросскомпиляцию и отладку, но есть некоторые проблемы пример
.
Так что сейчас удобнее работать так: устанавливаем WSL с любимой системой (при желании настраиваем XServer, хотя пишут, что для последней версии WSL даже этого на надо) и из под неё кроскомпилируем (и даже удалённо отлаживаем).
BFE>>Т.е. если на сайте поставщика системы написано, что они рекомендуют использовать, скажем, Ubuntu такой-то версии, то мы берём эту Ubuntu указанной версии ЕМ>Вот это меня тоже всегда поражало в линуксах — в системах, созданных и продвигаемых под эгидой взаимной совместимости, шаманства от возможной несовместимости наблюдается подозрительно много.
Разве взаимная совместимость кем-то декларировалась? Вроде бы нет. Разве что на уровне исходников и то: только при одинаковом наборе версий библиотек.
Здравствуйте, B0FEE664, Вы писали:
BFE>Прошло 5 лет и сейчас стало намного проще: новые версии gcc хорошо понимают ARM архитектуру
Что мешало им отлично ее понимать еще 15-20 лет назад, когда она более-менее заметно пошла в работу?
BFE>проблем с компиляцией стало существенно меньше.
Так их не должно быть вообще, если компилятор/линкер явно не кривые.
BFE>Можно даже из-под винды делать кросскомпиляцию и отладку, но есть некоторые проблемы BFE>пример
А менее надуманные проблемы есть?
BFE>сейчас удобнее работать так: устанавливаем WSL с любимой системой (при желании настраиваем XServer, хотя пишут, что для последней версии WSL даже этого на надо) и из под неё кроскомпилируем (и даже удалённо отлаживаем).
Это всегда было удобнее, отчего и возникла идея кросс-компиляции. Под ту же винду так было с незапамятных времен — например, для Windows CE/Mobile под ARM/MIPS отродясь не было средств разработки, все делалось на интеловских десктопах. И линуксовые прошивки для большинства устройств на тех же ARM/MIPS физически невозможно собрать на целевой платформе — только кросс-средствами. Про микроконтроллеры и говорить нечего.
BFE>Разве взаимная совместимость кем-то декларировалась? Вроде бы нет. Разве что на уровне исходников и то: только при одинаковом наборе версий библиотек.
О том и речь, что идея системы, призванной обеспечить совместимость, вылилась в генератор всевозможных несовместимостей.
Здравствуйте, alpha21264, Вы писали:
Pzz>>А зачем ты это вообще делаешь? Чем плох кросс-скомпилированный исполняемый файл?
A>Тем, что я не хочу трахаться с кросс-компиляцией. A>Объяснить тебе какие проблемы вызывает кросс-компиляция?
Мне кажется, больше половины тех программ, которыя я так или иначе в жизни писал, кросс-компилировались. Я привык.
Здравствуйте, Pzz, Вы писали:
A>>Объяснить тебе какие проблемы вызывает кросс-компиляция?
Pzz>Мне кажется, больше половины тех программ, которыя я так или иначе в жизни писал, кросс-компилировались. Я привык.
Здравствуйте, Евгений Музыченко, Вы писали:
BFE>>Прошло 5 лет и сейчас стало намного проще: новые версии gcc хорошо понимают ARM архитектуру ЕМ>Что мешало им отлично ее понимать еще 15-20 лет назад, когда она более-менее заметно пошла в работу?
Я могу только догадываться.
BFE>>проблем с компиляцией стало существенно меньше. ЕМ>Так их не должно быть вообще, если компилятор/линкер явно не кривые.
Проблема не только в компиляторах/линкерах, но и в библиотеках.
BFE>>Можно даже из-под винды делать кросскомпиляцию и отладку, но есть некоторые проблемы BFE>>пример
. ЕМ>А менее надуманные проблемы есть?
В смысле — надуманные? Это реальная проблема и вряд ли её кто-то будет чинить.
Но есть и другие. Скажем есть библиотека, а она подключает заголовок, которой нет в системе. Значит этот файл надо копировать из системы, а он тянет другой и так все файлы, один за другим переползают в sysroot...
и как только окажется, что sysroot есть линки, то процесс копирования файлов перестаёт быть томным.
И если окажется, что компилятор по какой-то причине не понимает вот этот вот заголовок из недр sysroot'a или понимает его не правильно...
BFE>>сейчас удобнее работать так: устанавливаем WSL с любимой системой (при желании настраиваем XServer, хотя пишут, что для последней версии WSL даже этого на надо) и из под неё кроскомпилируем (и даже удалённо отлаживаем). ЕМ>Это всегда было удобнее, отчего и возникла идея кросс-компиляции.
Это никогда не было удобным, а практика кросс-компиляции возникла из-за нехватки ресурсов для разработки на целевой платформа.
ЕМ>Под ту же винду так было с незапамятных времен — например, для Windows CE/Mobile под ARM/MIPS отродясь не было средств разработки, все делалось на интеловских десктопах. И линуксовые прошивки для большинства устройств на тех же ARM/MIPS физически невозможно собрать на целевой платформе — только кросс-средствами. Про микроконтроллеры и говорить нечего.
И несмотря на многолетние наработки безглючных средств отладки так и не было произведено.
BFE>>Разве взаимная совместимость кем-то декларировалась? Вроде бы нет. Разве что на уровне исходников и то: только при одинаковом наборе версий библиотек. ЕМ>О том и речь, что идея системы, призванной обеспечить совместимость, вылилась в генератор всевозможных несовместимостей.
Так ведь не было такой идеи. Ну или я о ней никогда не слышал.
Здравствуйте, Евгений Музыченко, Вы писали:
Pzz>>Мне кажется, больше половины тех программ, которыя я так или иначе в жизни писал, кросс-компилировались. Я привык.
ЕМ>И что, много было проблем?
Здравствуйте, B0FEE664, Вы писали:
BFE>Проблема не только в компиляторах/линкерах, но и в библиотеках.
А там в чем проблема? Если библиотека распространяется только в двоичном виде, то к целевой платформе ее не присобачить никак. Если же в исходниках, то какая разница, где ее компилить/собирать — на целевой платформе, или на рабочей? Здесь я тоже вижу проблему лишь в том случае, когда целевая платформа обкатана, широко используется и имеет развитый набор средств для компиляции/сборки, а та платформа, на которой вдруг приспичило собрать, имеет лишь какой-то урезанный набор. Но тогда возникает вопрос — откуда вообще взялась идея собирать не на целевой?
BFE>В смысле — надуманные? Это реальная проблема
В том посте, на который ссылка, я вижу только искусственно созданные длинные пути. Допускаю, что и в реальных применениях случаются настолько развесистые имена/вложенности, что не влезают в 260 символов, но это явная редкость. В винде ограничение в MAX_PATH кончилось с кончиной 9x/ME, а в NT оно осталось только для ANSI-версий. Чтобы это убрать, достаточно переопределить fopen, findfirst и прочее через соответствующие Unicode-аналоги, добавив трансляцию. Но, исходя из
BFE>и вряд ли её кто-то будет чинить.
подавляющее большинство это не парит, а нарываются лишь любители_чрезмерно_длинных_имен, которых в общей массе крайне мало.
BFE>есть библиотека, а она подключает заголовок, которой нет в системе.
Вот это "заголовки, которые есть в системе" — один из основных источников боли, связанной с линуксами. Обязательное условие наличия в системе компилятора, линкера, заголовков и библиотек сродни требованию о том, чтобы в каждом автомобиле был полный набор инструментов и материалов, позволяющий собрать его с нуля в чистом поле. Это вполне нормально выглядело в древности, но последние лет тридцать это явное извращение. Все эти средства должны быть в виде отдельных, изолированных наборов, и ставиться/подключаться в том составе, что необходим конкретному разработчику.
BFE>Значит этот файл надо копировать из системы, а он тянет другой и так все файлы, один за другим переползают в sysroot...
Вместо этого должны быть явно определенные зависимости — какие именно SDK и библиотеки нужны для сборки. А не бесформенная куча файлов из разных источников в одном месте.
BFE>И если окажется, что компилятор по какой-то причине не понимает вот этот вот заголовок из недр sysroot'a или понимает его не правильно...
Почему такое вдруг может оказаться? Если библиотека заточена под конкретный компилятор или конкретную его версию, то вероятность найти такой компилятор для "большой", ходовой системы должна быть выше, чем для "малой" целевой.
BFE>практика кросс-компиляции возникла из-за нехватки ресурсов для разработки на целевой платформа.
Фраза верна, только слово "ресурсов" здесь нужно понимать не "скорости процессора и объема памяти", а ресурсов вообще — стоимости железа, софта, рабочего места разработчиков, их труда и т.п. Кросс-компиляция возникла где-то в 50-х годах прошлого века, когда сообразили, что при разработке софта для новой машины, в традиционном цикле "ассемблер в кодах, ассемблер на самом себе, компилятор ЯВУ на этом ассемблере" начальные этапы можно пропустить, переделав готовые ассемблер/компилятор для существующей машины под кодогенерацию для новой машины.
А так-то, у любой современной видеокарты ресурсов по уши хватит для сборки того же линукса, только где Вы видели линуксы и компиляторы, работающие непосредственно на видеокартах?
BFE>И несмотря на многолетние наработки безглючных средств отладки так и не было произведено.
Значит, определенный уровень глючности устраивает подавляющее большинство настолько, что дальше бороться с глюками просто лень. Хотя опять не понимаю, в чем может быть проблема сделать сколь угодно безглючные средства удаленной отладки для любого сочетания платформ.
ЕМ>>идея системы, призванной обеспечить совместимость
BFE>Так ведь не было такой идеи.
Почти в любом описании идеологии *nix-систем подчеркивается идея совместимости софта. Врут?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>А там в чем проблема? Если библиотека распространяется только в двоичном виде, то к целевой платформе ее не присобачить никак. Если же в исходниках, то какая разница, где ее компилить/собирать — на целевой платформе, или на рабочей? Здесь я тоже вижу проблему лишь в том случае, когда целевая платформа обкатана, широко используется и имеет развитый набор средств для компиляции/сборки, а та платформа, на которой вдруг приспичило собрать, имеет лишь какой-то урезанный набор. Но тогда возникает вопрос — откуда вообще взялась идея собирать не на целевой?
Библиотеки в исходникам. Прежде, чем их собрать, их нужно сконфигурировать. Обычно конфигурация — это такой набор define'ов, который включает/выключает те или иные особенности в коде библиотеки. Или, там, определяет размер int'а в байтах... Часто вместе с библиотекой идёт скрипт, который, например, может скомпилировать тестовый пример, запустить его и по выданному результату добавить тот или иной define в config.h, а этот config.h потом, на этапе компиляции библиотеки, подхватывается и используется. Так вот эту конфигурацию надо проводить на target системе, а для этого там нужно установить компилятор... Ну или потратить несколько дней рассматривая код и подбирая подходящие define'ы.
BFE>>В смысле — надуманные? Это реальная проблема ЕМ>В том посте, на который ссылка, я вижу только искусственно созданные длинные пути.
А вам хотелось бы увидеть реальные строки из моей рабочей системы? Зачем? С какой целью интересуетесь?
ЕМ>Допускаю, что и в реальных применениях случаются настолько развесистые имена/вложенности, что не влезают в 260 символов, но это явная редкость.
Да ну какая там редкость! Просто ограничение в винде накладывают естественным образом ограничения на пользователей, а вот начинаешь что-нибудь развесистое из другой системы копировать и облом.
ЕМ>В винде ограничение в MAX_PATH кончилось с кончиной 9x/ME, а в NT оно осталось только для ANSI-версий. Чтобы это убрать, достаточно переопределить fopen, findfirst и прочее через соответствующие Unicode-аналоги, добавив трансляцию.
Все исходники открыты, можете заняться.
ЕМ>Но, исходя из BFE>>и вряд ли её кто-то будет чинить. ЕМ>подавляющее большинство это не парит, а нарываются лишь любители_чрезмерно_длинных_имен, которых в общей массе крайне мало.
Это не будут чинить по другой причине: поставил WSL и нет таких проблем.
BFE>>есть библиотека, а она подключает заголовок, которой нет в системе. ЕМ>Вот это "заголовки, которые есть в системе" — один из основных источников боли, связанной с линуксами. Обязательное условие наличия в системе компилятора, линкера, заголовков и библиотек сродни требованию о том, чтобы в каждом автомобиле был полный набор инструментов и материалов, позволяющий собрать его с нуля в чистом поле. Это вполне нормально выглядело в древности, но последние лет тридцать это явное извращение. Все эти средства должны быть в виде отдельных, изолированных наборов, и ставиться/подключаться в том составе, что необходим конкретному разработчику.
А я спорю? Но вы попробуйте убедить какого-нибудь линуксоида устанавливать библиотеки не в систему, а домашний каталог. Заранее предупреждаю, что за разрыв шаблона ответственность на себя брать не буду.
BFE>>Значит этот файл надо копировать из системы, а он тянет другой и так все файлы, один за другим переползают в sysroot... ЕМ>Вместо этого должны быть явно определенные зависимости — какие именно SDK и библиотеки нужны для сборки. А не бесформенная куча файлов из разных источников в одном месте.
Ну раз должны, тогда надо назначить ответственного. Есть кандидаты?
BFE>>И если окажется, что компилятор по какой-то причине не понимает вот этот вот заголовок из недр sysroot'a или понимает его не правильно... ЕМ>Почему такое вдруг может оказаться? Если библиотека заточена под конкретный компилятор или конкретную его версию, то вероятность найти такой компилятор для "большой", ходовой системы должна быть выше, чем для "малой" целевой.
Да мало ли любителей переопределять unsigned int в UI32 ? Или приводить указатель на структуру к int'у?
BFE>>Так ведь не было такой идеи. ЕМ>Почти в любом описании идеологии *nix-систем подчеркивается идея совместимости софта. Врут?
Да где вы такое читали? Это в Windows обратная совместимость вплоть до DOSа и ограничение в 256+4 . А в *nix-е у каждого маньяка свой лунапарк с блэкджеком и командой print:
"типичный последователь UNIX'а никогда не может запомнить, как на этой неделе называется команда PRINT" (с) старая классика
Здравствуйте, B0FEE664, Вы писали:
BFE>Часто вместе с библиотекой идёт скрипт, который, например, может скомпилировать тестовый пример, запустить его и по выданному результату добавить тот или иной define в config.h, а этот config.h потом, на этапе компиляции библиотеки, подхватывается и используется. Так вот эту конфигурацию надо проводить на target системе, а для этого там нужно установить компилятор... Ну или потратить несколько дней рассматривая код и подбирая подходящие define'ы.
Это какая-то крайне извращенная технология. Если параметрами библиотеки являются известные, фиксированные свойства целевой системы — они должны быть документированы и там, и там, и никаких сложностей с заданием значений возникать не должно. Если же библиотеке нужна "тонкая настройка" на целевую платформу (какие-то нюансы аппаратной или программной конфигурации, производительности и т.п.), то конфигуратор должен быть сделан так, чтобы собрать его кросс-средствами было предельно просто, в идеале — в одну командную строку. Ну и так заморачиваться со статической конфигурацией имеет смысл лишь в том случае, когда динамическая (при инициализации библиотеки уже на целевой платформе) обходится неоправданно дорого.
То есть, проблема снова не в кросс-компиляции, как таковой, а в явной кривизне софта, ей подвергаемого.
BFE>вам хотелось бы увидеть реальные строки из моей рабочей системы?
Да хоть бы пути с измененными именами примерно той же длины, чтобы стало более-менее понятно — реальная там необходимость в длинных путях, или просто причуда.
BFE>Просто ограничение в винде накладывают естественным образом ограничения на пользователей, а вот начинаешь что-нибудь развесистое из другой системы копировать и облом.
Вот и вопрос, отчего оно в той системе такое развесистое. Скажем, насколько часто в программах на C++ встречаются имена, полная запись которых (со всеми namespace-ами, именами классов и прочим) дотянет хотя бы до 200 символов?
BFE>Все исходники открыты, можете заняться.
А мне оно на хрена? Я предпочитаю называть каталоги именами разумной длины, чтоб путь, по возможности, не превышал 100-120 символов.
BFE>Это не будут чинить по другой причине: поставил WSL и нет таких проблем.
А по какой причине не чинили пятнадцать лет до появления WSL?
BFE>попробуйте убедить какого-нибудь линуксоида устанавливать библиотеки не в систему, а домашний каталог.
Тогда, наверное, стоило бы при обсуждении проблем с кросс-компиляцией оговаривать, что бОльшая их часть возникает от кривизны рук на разных уровнях.
BFE>Ну раз должны, тогда надо назначить ответственного. Есть кандидаты?
Ну а кто там в Linux-сообществе отвечает за разработку стандартов и рекомендаций? Вот их и назначать.
BFE>Да мало ли любителей переопределять unsigned int в UI32 ? Или приводить указатель на структуру к int'у?
Если это делается грамотно и корректно в рамках поддерживаемых архитектур — пусть хоть к char'у приводят, но пишут в документации: "библиотека не поддерживает архитектуры, размер указателей в которых превышает sizeof (char)".
ЕМ>>Почти в любом описании идеологии *nix-систем подчеркивается идея совместимости софта. Врут?
BFE>Да где вы такое читали?
Почти в любой статье о "Unix Philosophy" упоминается о portability over efficiency. А как добиться portability без compatibility?
Здравствуйте, Евгений Музыченко, Вы писали:
A>>Объяснить тебе какие проблемы вызывает кросс-компиляция?
ЕМ>А можно мне?
1) Она не работает. Ты конечно можешь её заставить (иногда),
но она будет всё время отваливаться по самым идиотским причинам и в произвольные моменты времени.
2) Она обязательно соберёт не то. Не под ту архитектуру, не под ту версию.
3) Будешь трахаться с библиотеками и их версиями. На Raspberry у тебя всегда будет одно, на PC другое.
Современной программе всегда нужно не менее 100 разных библиотек.
4) Что-то нужно мудрить с инсталлятором. make install как правило не прокатывает.
5) Оно может конфликтовать с твоей основной средой разработки.
В общем — этим можно заниматься, но только если ты можешь на это тратить полный рабочий день и тебе за это платят.
А если тебе за это не платят, проще установить gcc на саму Raspberry.
Здравствуйте, novitk, Вы писали:
A>>Тем, что я не хочу трахаться с кросс-компиляцией. A>>Объяснить тебе какие проблемы вызывает кросс-компиляция?
N>И какие же? Для большинства MC кросс-компиляция единственный вариант, например та же ардуина.
Мы про Raspberry Pi говорим. Это — полноценный компьютер с полноценным линуксом.
Здравствуйте, c-smile, Вы писали:
CS>Насколько я понимаю это надо делать true Linux way — собирать его на target устройстве.
Зачем?
CS>Альтернативно можно попробовать cross-compiling, но насколько я понимаю это работает только для простых случаев. Или я ошибаюсь?
Ошибаешься.
CS>Вообще у кого есть практический опыт разработки под Raspberry Pi или чего-то аналогичного, как это правильно делать?
Я очень много времени провел в embedded разработке.
В общем, твоя проблема в том, чтобы найти cross-тулчейн с достаточно большим набором библиотек под него, чтобы он покрывал твои нужды. Поищи, не найдешь — возвращайся. Собираться на самой малинке, ну, я бы такой вариант рассматривал, как запасной. Все-таки на хосте у тебя побольше мегагерцев будет, чем на устройстве.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вот это "заголовки, которые есть в системе" — один из основных источников боли, связанной с линуксами. Обязательное условие наличия в системе компилятора, линкера, заголовков и библиотек сродни требованию о том, чтобы в каждом автомобиле был полный набор инструментов и материалов, позволяющий собрать его с нуля в чистом поле. Это вполне нормально выглядело в древности, но последние лет тридцать это явное извращение. Все эти средства должны быть в виде отдельных, изолированных наборов, и ставиться/подключаться в том составе, что необходим конкретному разработчику.
Вот +100500. В винде и в макоси давно всё нормально сделано, есть platform SDK, там всё что тебе надо. Можно поставить их несколько и говорить с какой ты хочешь компилять.
А в линухах до сих пор какие то палки копалки на каждый чих.
ЕМ>Вместо этого должны быть явно определенные зависимости — какие именно SDK и библиотеки нужны для сборки. А не бесформенная куча файлов из разных источников в одном месте.
+100500 №2
ЕМ>Почему такое вдруг может оказаться? Если библиотека заточена под конкретный компилятор или конкретную его версию, то вероятность найти такой компилятор для "большой", ходовой системы должна быть выше, чем для "малой" целевой.
+1
ЕМ>Почти в любом описании идеологии *nix-систем подчеркивается идея совместимости софта. Врут?
Врут, причём я бы даже сказал что наглейшим образом пи%дят.
Хуже совместимости я не видел ещё нигде. Винда и мак просто на световые годы по обеспечению совместимости ушли вперёд.
Здравствуйте, alpha21264, Вы писали:
A> Современной программе всегда нужно не менее 100 разных библиотек.
Почему то сразу вспоминается пресловутый leftpad
Здравствуйте, alpha21264, Вы писали:
A>1) Она не работает. Ты конечно можешь её заставить (иногда), A> но она будет всё время отваливаться по самым идиотским причинам и в произвольные моменты времени.
Возможно, я что-то делаю не так, но у меня она работает всегда и не отваливается. Возможно, я что-то делаю не так — например, делаю ее под виндой.
A>2) Она обязательно соберёт не то. Не под ту архитектуру, не под ту версию.
Ни разу такого не было. Очевидно, виновата винда.
A>3) Будешь трахаться с библиотеками и их версиями.
С ними приходится трахаться почти всегда, когда они используются, независимо от платформ.
A>На Raspberry у тебя всегда будет одно, на PC другое.
Это опять же из-за кривой идеологии *nix ("в каждой системе обязана быть среда для сборки"), от которой польза только для типовых вариантов, а для нетиповых — сплошной вред. В виндовых средствах сборки принципиально нет понятия "родной среды" — все необходимые средства всегда устанавливаются независимо, в той конфигурации, которая необходима. Конечно, бывают проекты с инструкциями вроде "собирать только под VS 2015.3", но и это всего лишь означает набор известных заголовочных/библиотечных файлов, не более того.
Если мне вдруг приспичит поднять на винде под Raspberry среду для сборки, под нею соберутся правильные бинарники с той же функциональностью, что и под виндой на x64 — хоть для arm64, хоть для x64, хоть для x86. Даже представить себе не могу, что там нужно сделать, чтобы оно вдруг не собралось, или собралось неправильно. Различия могут быть лишь в чисто технических мелочах вроде порядка секций, для которых тот порядок не задан явно — если версии компилятора/линкера будут разными. Одинаковые версии соберут полностью идентичные бинарники и там, и там.
A>Современной программе всегда нужно не менее 100 разных библиотек.
Всегда? Не менее? Точно?
A>4) Что-то нужно мудрить с инсталлятором. make install как правило не прокатывает.
Если скрипты для установки написаны под конкретную версию/конфигурацию системы, то это предсказуемо. Если заявлено, что они могут обслуживать множество систем, но не делают этого — они просто кривые. Но только при чем здесь кросс-компиляция, как таковая? Так и говорите — "скрипты, написанные для халявной сборки под целевой системой, ломаются при изменении конфигурации".
A>5) Оно может конфликтовать с твоей основной средой разработки.
Каким образом? Конечно, если в лучших линуксовых традициях сваливать все заголовки/библиотеки в одну "системную" кучу, в которой они видны глобально и находятся по общим путям, то неудивительно. И сама кросс-компиляция здесь снова ни при чем.
Здравствуйте, alpha21264, Вы писали:
N>>Для большинства MC кросс-компиляция единственный вариант, например та же ардуина.
A>Мы про Raspberry Pi говорим. Это — полноценный компьютер с полноценным линуксом.
Тогда получается, что средства кросс-компиляции и проекты для недокомпьютеров сделаны лучше, чем для "полноценных".
Здравствуйте, Pzz, Вы писали:
CS>>true Linux way — собирать его на target устройстве.
Pzz>Зачем?
Дабы соответствовать.
Помнится, когда-то давно знакомая в разговоре упомянула, что у нее подросла собака, ей "пора купировать уши". На мой вопрос, зачем это нужно, ответила "чтобы соответствовала породе". Следующие полчаса я старательно пытался выяснить, зачем она собирается уродовать животину, но та лишь твердила "мне объяснили, что это требуется для соответствия породе". Тогда эта дама сильно упала в моих глазах.
Позже я где-то прочитал, что та порода была выведена искусственно, и с ушами у этих собак часто возникали проблемы, отчего их и старались подрезать заранее. Но дама в это не вникала, и просто собиралась тупо исполнить то, что ей сообщили то ли в ветеринарке, то ли в собачьем клубе.
Здравствуйте, CreatorCray, Вы писали:
CC>В винде и в макоси давно всё нормально сделано, есть platform SDK, там всё что тебе надо. Можно поставить их несколько и говорить с какой ты хочешь компилять.
В винде в последнее время тоже доминирует тенденция к неграмотности. Даже многие разработчики драйверов весьма туманно представляют себе, что происходит про сборке, и мыслят категориями "ставим такую-то студию, к ней ставим такой-то WDK, создаем проект, нажимаем кнопку, и крутая магия создает нам бинарники".
Но даже при таком подходе сохраняется принцип разделимости. Я SDK/WDK уже много лет не ставлю их собственными установщиками, а тупо распаковываю из MSI нужные подкаталоги в отдельные целевые каталоги, и в каждом проекте указываю соответствующие пути. Немного более громоздко, чем стандартный способ, зато нигде нет неявных зависимостей — все на виду.
Вообще, импортировать заголовки/библиотеки тупо по [коротким и невнятным] именам, в расчете на то, что все пути будут свалены в INCLUDE/LIB, допустимо или в сугубо локальных проектах, не предназначенных к распространению, или когда импортируемые файлы имеют давно устоявшиеся, незыблемые имена (stdio.h, libc и т.п.). Но до сих пор ведь встречаются публичные проекты с чем-то вроде #include <util.h>, где util.h — заголовок в одной из нескольких внешних библиотек.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>В винде в последнее время тоже доминирует тенденция к неграмотности.
Увы, идиократия была документалкой, да.
Здравствуйте, Евгений Музыченко, Вы писали:
CC>>В винде и в макоси давно всё нормально сделано, есть platform SDK, там всё что тебе надо. Можно поставить их несколько и говорить с какой ты хочешь компилять.
ЕМ>В винде в последнее время тоже доминирует тенденция к неграмотности. Даже многие разработчики драйверов весьма туманно представляют себе, что происходит про сборке, и мыслят категориями "ставим такую-то студию, к ней ставим такой-то WDK, создаем проект, нажимаем кнопку, и крутая магия создает нам бинарники".
Как тебе удаётся в одной теме говорить правильные вещи, и в той же теме самому садиться в ту же лужу?
Ты мыслишь категориями "ставим кросс-систему, и крутая магия создаёт нам бинарник, а если не создаёт, то она кривая".
Кросс-системы для малины прямые. На Дебиане на любой платформе уже много лет из коробки, безо всякого напильника, можно создавать бинарник "Hello, world" под все четыре малиновых процессора.
Но "Hello, world" для малины не нужно кросс-компилировать. Он и на самой малине скомпилируется за секунду.
Кросс-компилировать для малины может понадобится большие штуки, которые на малине будут собираться часами. Это значит мегабайты исходных кодов самого приложения и десятки посторонних библиотек, которых гарантированно не будет в самой прямой кросс-системе. И все эти десятки чужих библиотек, подобранных автором целевого продукта по функционалу, а не по качеству подготовки к кросс-компиляции, нужно допилить и кросс-компилировать. В этом трах.
Да, этой проблемы нет при разработке под микрокалькуляторыконтроллеры.
ЕМ>Но даже при таком подходе сохраняется принцип разделимости. Я SDK/WDK уже много лет не ставлю их собственными установщиками, а тупо распаковываю из MSI нужные подкаталоги в отдельные целевые каталоги, и в каждом проекте указываю соответствующие пути. Немного более громоздко, чем стандартный способ, зато нигде нет неявных зависимостей — все на виду.
Теперь представь, что таких SDK надо поставить тридцать. Потому что сейчас модно не писать руками то, что можно подтянуть из чужой библиотеки, и плевать на качество оформления библиотеки, у меня же собралось.
ЕМ>Вообще, импортировать заголовки/библиотеки тупо по [коротким и невнятным] именам, в расчете на то, что все пути будут свалены в INCLUDE/LIB, допустимо или в сугубо локальных проектах, не предназначенных к распространению, или когда импортируемые файлы имеют давно устоявшиеся, незыблемые имена (stdio.h, libc и т.п.). Но до сих пор ведь встречаются публичные проекты с чем-то вроде #include <util.h>, где util.h — заголовок в одной из нескольких внешних библиотек.
Видишь, одну из самых простых проблем при сборке публичных проектов ты уже знаешь. Главное не копай глубже, там ещё хуже.
Здравствуйте, /aka/, Вы писали:
A>Ты мыслишь категориями "ставим кросс-систему, и крутая магия создаёт нам бинарник, а если не создаёт, то она кривая".
Нет, я мыслю примерно так: "если моя основная рабочая система, где все удобно настроено, может собрать бинарники для другой целевой системы, под которой я не работаю регулярно, и там нет удобной среды для сборки, то откуда вообще может взяться идея делать это непосредственно на целевой системе?".
A>"Hello, world" для малины не нужно кросс-компилировать. Он и на самой малине скомпилируется за секунду.
Вот в этом-то все и дело. За десятилетия развития программирования сложилась вполне адекватная практика: средства разработки должны находиться и работать в той системе, где ведется эта самая разработка, а на целевые системы, где разработки не ведется, должны поступать уже готовые бинарники. От этого отступают лишь при крайней необходимости. Когда-то давно любой *nix автоматически являлся и системой разработки под себя, поэтому наличие в нем средств разработки было вполне оправдано. Когда же стали делать на базе него системы, где разработки не предполагалось, следовало как можно быстрее избавляться от традиции прилагать к каждому экземпляру системы еще и комплект из компилятора/линкера, заголовков и библиотек, как когда-то отказались от комплектации каждого автомобиля сундуком с инструментами и запчастями. Но традиция оказалась настолько прилипчивой, что идея жить на вечной стройке завоевала массы, и теперь вам от нее никуда не деться. Именно отсюда и растет корень многих ваших проблем.
A>Кросс-компилировать для малины может понадобится большие штуки, которые на малине будут собираться часами. Это значит мегабайты исходных кодов самого приложения и десятки посторонних библиотек, которых гарантированно не будет в самой прямой кросс-системе.
Так их и не должно там быть. Кросс-система — это набор базовых средств (компилятор, линкер и прочие build tools, стандартные заголовки, библиотеки, универсальные скрипты), с помощью которых можно собирать хоть "hello, world", хоть линукс, под любую из необходимых платформ. Все остальное добавляется отдельно, в явном виде, в нужном сочетании.
Соответственно, если разработка приложения ведется на той самой малине, то логично, чтобы все это было там. Если же разработка ведется в другой системе, то все это логично ставить в нее, а на малине, где не ведется разработка, вообще нет оснований держать что-то из этого.
A>И все эти десятки чужих библиотек, подобранных автором целевого продукта по функционалу, а не по качеству подготовки к кросс-компиляции, нужно допилить и кросс-компилировать. В этом трах.
Потому и трах, что разработчики этих библиотек, грубо говоря, привыкли и работать, и есть, и спать на одном месте, раскладывая всё необходимое вокруг себя, на расстоянии вытянутой руки. О том, что существуют рабочие кабинеты, кухни, столовые и спальни, а также ящики и шкафы, они либо не догадываются (если слаще морковки ничего не видали), либо убеждены, что все это лишнее, и настоящему линуксоиду только вредит.
Забавно, что винда и ее средства разработки, где изначально все было свалено в одну кучу, давно вышли из этого состояния, а в линуксе, вырасшем из униха с его строгим и разумным разделением по принадлежности разных средств, так и остался в идеологии 70-80-х.
A>Теперь представь, что таких SDK надо поставить тридцать.
Да хоть сто, если они сделаны минимально грамотно, а потому не конфликтуют ни друг с другом, ни с системой сборки. Главное, что их достаточно поставить в одну систему — основную, рабочую. А с целевой контактировать лишь постольку, поскольку это нужно для тестирования и отладки.
A>Потому что сейчас модно не писать руками то, что можно подтянуть из чужой библиотеки, и плевать на качество оформления библиотеки, у меня же собралось.
А качество оформления непосредственно вытекает из устоявшейся практики. Вот в унихах изначально была логика распределения и файлов по каталогам, и прав по пользователям, поэтому с этим изначально был относительный порядок. В досе/винде ничего этого не было, поэтому было принято "валить все в систему", и в этом говнище тоже "все собиралось". Потом MS нашел в себе силы поломать эту практику, и уже давно все выглядит достаточно пристойно, в кучу валят лишь самые отморозки. А линукс, наоборот, так и тянет эту порочную практику. Если даже сейчас начать изо всех сил ее искоренять, пройдет лет пять-семь, пока оно сдвинется. Так что вам еще долго с этим жить.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>...когда-то отказались от комплектации каждого автомобиля сундуком с инструментами и запчастями. Но традиция оказалась настолько прилипчивой, что идея жить на вечной стройке завоевала массы, и теперь вам от нее никуда не деться. Именно отсюда и растет корень многих ваших проблем.
У нас нет проблем. Мы можем собирать на разных системах. И у нас хватает опыта выбирать, где это делать удобнее.
Это у тебя проблема понять, что мы объясняем. Вероятно, от отсутствия релевантного опыта.
Про микрокалькуляторыконтроллеры понятно, там выбора нет. Ты вынужден собирать на одной системе, а использовать на другой.
Под какие разные платоформы разных производителей, на которых есть свои среды разработки, ты можешь кросс-компилировать на виндовсе?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Помнится, когда-то давно знакомая в разговоре упомянула, что у нее подросла собака, ей "пора купировать уши". На мой вопрос, зачем это нужно, ответила "чтобы соответствовала породе". Следующие полчаса я старательно пытался выяснить, зачем она собирается уродовать животину, но та лишь твердила "мне объяснили, что это требуется для соответствия породе". Тогда эта дама сильно упала в моих глазах.
Ну если она по выставкам собирается таскаться со своей собачкой, то соответствие породе может быть существенным условием.
(хорошо, что у меня дворняжка, соответствующая своей породе по определению, в любом своем состоянии).
ЕМ>Позже я где-то прочитал, что та порода была выведена искусственно, и с ушами у этих собак часто возникали проблемы, отчего их и старались подрезать заранее. Но дама в это не вникала, и просто собиралась тупо исполнить то, что ей сообщили то ли в ветеринарке, то ли в собачьем клубе.
Проблемы могли возникать при использовании породы по назначению. Например, на охоте. Большинство пород выведены вполне в рабочих целях, а не в декоративных, как они сейчас используются.
Здравствуйте, Евгений Музыченко, Вы писали:
N>>>Для большинства MC кросс-компиляция единственный вариант, например та же ардуина.
A>>Мы про Raspberry Pi говорим. Это — полноценный компьютер с полноценным линуксом.
ЕМ>Тогда получается, что средства кросс-компиляции и проекты для недокомпьютеров сделаны лучше, чем для "полноценных".
Не получается. У тебя что-то с логикой.
На полноценном компьютере можно работать полноценно —
без привлечения других ненужных устройств,
на которые нужно тратить деньги, место и главное — мозги.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Дабы соответствовать.
ЕМ>Помнится, когда-то давно знакомая в разговоре упомянула, что у нее подросла собака, ей "пора купировать уши". На мой вопрос, зачем это нужно, ответила "чтобы соответствовала породе". Следующие полчаса я старательно пытался выяснить, зачем она собирается уродовать животину, но та лишь твердила "мне объяснили, что это требуется для соответствия породе". Тогда эта дама сильно упала в моих глазах.
ЕМ>Позже я где-то прочитал, что та порода была выведена искусственно, и с ушами у этих собак часто возникали проблемы, отчего их и старались подрезать заранее. Но дама в это не вникала, и просто собиралась тупо исполнить то, что ей сообщили то ли в ветеринарке, то ли в собачьем клубе.
И что характерно — дама оказалась права, несмотря на то, что не понимала, что творила (и почему).
Вот так и у нас true Linux way возник не просто так. Он возник в результате естественного отбора.
Здравствуйте, /aka/, Вы писали:
A>Мы можем собирать на разных системах. И у нас хватает опыта выбирать, где это делать удобнее.
Мне интересно, за счет чего может быть реально удобнее что-то собирать в системе, с которой не работаешь сколько-нибудь регулярно, в которой не настроена комфортная для этого среда. В то, что приходится от безысходности, верю охотно — бинарники от других версий той же системы не подходят (это отдельная проблема линуксов), для этой версии еще никто не собрал, поэтому извольте собирать сами. Но чтоб именно удобно — сомнительно мне.
A>Это у тебя проблема понять, что мы объясняем. Вероятно, от отсутствия релевантного опыта.
Ну да, я никогда не увлекался линуксовым софтом, но кое-что собирать приходилось. И каждый раз применялся тот же подход — "добавьте пути в path/include/lib (то есть, досыпьте в ту кучу еще и это) и запустите make". Достоинства этого подхода лишь в том, что в типовых, ходовых вариантах это почти не требует затрат. Но по мере отхода от типовых вариантов затраты растут очень быстро, о чем тут многократно упоминалось. Оно точно этого стоит?
A>Про микрокалькуляторыконтроллеры понятно, там выбора нет. Ты вынужден собирать на одной системе, а использовать на другой.
Почему "вынужден"? Если у меня есть рабочая конфигурация под конкретной системой, на конкретном рабочем месте, настроенная конкретно под меня, то я предпочту собирать на ней для чего угодно — в том числе и для более мощной системы, которая просто не приспособлена для комфортной работы. А если та система приспособлена для работы лучше, то почему я до сих пор работаю на этой?
Исключение можно сделать разве что для случая, когда приходится примерно одинаково плотно работать под каждой из систем, и каждая более-менее заточена под это. Но это очень далеко от ситуации ТС, которому та Raspberry сама по себе вообще на хрен не упала, а тупо надо было сделать бинарники для клиентов.
A>Под какие разные платоформы разных производителей, на которых есть свои среды разработки, ты можешь кросс-компилировать на виндовсе?
Под линуксы, макось и андроид, а какие еще существуют ОС с собственными системами разработки?
Здравствуйте, alpha21264, Вы писали:
A>>>Мы про Raspberry Pi говорим. Это — полноценный компьютер с полноценным линуксом.
A>На полноценном компьютере можно работать полноценно — A>без привлечения других ненужных устройств,
Я правильно понимаю, что Вы уже давно работаете исключительно на Raspberry Pi, без привлечения десктопов/ноутбуков на x86/x64?
Здравствуйте, Евгений Музыченко, Вы писали:
A>>Это у тебя проблема понять, что мы объясняем. Вероятно, от отсутствия релевантного опыта. ЕМ>Оно точно этого стоит?
Конечно. Потому что альтернатив нет. Только под линуксом я могу взять что-то из 100500 публичных проектов на гитхаба и собрать его на малине, совершенно другой платформе, которую автор никогда не видел. Собрать для виндовса что-то сложнее "Hello, World", если оно не написано для виндвоса, чаще всего не получается, даже если писалось оно на той же x86.
A>>Про микрокалькуляторыконтроллеры понятно, там выбора нет. Ты вынужден собирать на одной системе, а использовать на другой. ЕМ>Почему "вынужден"?
Потому что не микрокалькулятореконтроллере нет компилятора. Всегда ваш, Кэп.
A>>Под какие разные платоформы разных производителей, на которых есть свои среды разработки, ты можешь кросс-компилировать на виндовсе? ЕМ>Под линуксы, макось и андроид, а какие еще существуют ОС с собственными системами разработки?
Вау. Расскажи, какие публичные проекты ты собирал на виндовсе под линукс?
Здравствуйте, alpha21264, Вы писали:
A>Вот так и у нас true Linux way возник не просто так. Он возник в результате естественного отбора.
Это Вы к тому, что естественный отбор якобы отбирает все самое лучшее? А то ведь именно в результате естественного отбора возникли, например, попса, bloatware, российская олигархия и другие малоприятные образования.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Вот это меня тоже всегда поражало в линуксах — в системах, созданных и продвигаемых под эгидой взаимной совместимости, шаманства от возможной несовместимости наблюдается подозрительно много.
Глупостей не говори. Ты видел Винду на Raspberry? Вот ыменно.
Здравствуйте, Евгений Музыченко, Вы писали:
A>>Вот так и у нас true Linux way возник не просто так. Он возник в результате естественного отбора.
ЕМ>Это Вы к тому, что естественный отбор якобы отбирает все самое лучшее? А то ведь именно в результате естественного отбора возникли, например, попса, bloatware, российская олигархия и другие малоприятные образования.
Это очень далёкая аналогия. Настолько далёкая, что я даже не знаю, что тут аналогичного.
Здравствуйте, Евгений Музыченко, Вы писали:
K>>все советы по кросскомпилированию в интернете походят для несложных проектов, что-то комплексное придётся компилировать через боль.
ЕМ>Это может означать только то, что средства кросс-компиляции для линукса по определению кривы, и чрезмерно завязаны на локальную среду, чего в них быть не должно.
Это означает, что Линукс решает более сложные задачи. Такие задачи, за которые Виндовс даже не берётся.
Например полный набор программ для Raspberry Pi. Очевидно же.
Здравствуйте, alpha21264, Вы писали:
A>Ты видел Винду на Raspberry? Вот ыменно.
"Вот ыменно", что она там работает уже несколько лет. У меня нет самой платы, поэтому винда стоит в виртуалке под QEMU, а народ ее на Raspberry активно ставит и пользует — без труда найдете в сети отчеты и рекомендации. Официально MS выпускала для Raspberry только какую-то урезанную сборку, поэтому народ в основном собирает дистрибутивы из UUP. У меня в одной виртуалке готовый образ из таких, а во вторую ставил 22H2 с какого-то официального дистрибутива.
ЕМ>Особенно любопытно, как это объяснять тем, кто делает софт для микроконтроллеров Intel/PIC/AVR, для которых "нативных" компиляторов не существует в природе.
Причём тут кросс-компиляция под микроконтроллеры из под винды, если речь в данной ветке обсуждения совсем о другом?
ЕМ>Если на практике непрозрачно, причина может быть только одна — кривая кросс-система. Других причин не бывает.
Ну да, об том, собственно, и речь. Но. Ты ту прямую систему кросс-сборки ещё поди найди. Да, такие есть, но это частные случаи и исключения из общей тенденции.
Здравствуйте, /aka/, Вы писали:
ЕМ>>...когда-то отказались от комплектации каждого автомобиля сундуком с инструментами и запчастями. Но традиция оказалась настолько прилипчивой, что идея жить на вечной стройке завоевала массы, и теперь вам от нее никуда не деться. Именно отсюда и растет корень многих ваших проблем. A>У нас нет проблем. Мы можем собирать на разных системах. И у нас хватает опыта выбирать, где это делать удобнее. A>Это у тебя проблема понять, что мы объясняем. Вероятно, от отсутствия релевантного опыта. A>Про микрокалькуляторыконтроллеры понятно, там выбора нет. Ты вынужден собирать на одной системе, а использовать на другой. A>Под какие разные платоформы разных производителей, на которых есть свои среды разработки, ты можешь кросс-компилировать на виндовсе?
Ты похоже совсем не разбираешься в теме. Основная проблемность кросс-компиляции определяется целевой платформой, а не хостом.
Для хоста что линух что винда практически одинаковые и позволяют собирать длю любых не проблемных платформ.
А вот в топе проблемных целевых платформ однозначно находятся десктопные дистрибутивы Линуха. Это является следствием отсутствия спецификации API для ОС и из-за чего классические скрипты сборки под данные ОС начинают проверять не версию API (как делается во всех других приличных местах), а наличие каждой отдельной функции. Плюс ещё проблемы со статической сборкой "псевдосистемного" api как libc и получаем худшую целевую платформу из всех возможных. Что впрочем не удивительно, т.к. собственно такой ОС как "Линукс" нет. Есть ядро Linux и сотня разных дистрибутивов на его базе, с десятками несовместимых версий и плюс ещё в с случае ПО с GUI имеет десяток оболочек рабочего стола, что в итоге приводит ко многим тысячам несовместимых между собой вариантов. И вряд ли эту проблему можно как-то решить, разве что найдётся какой-то однозначный лидирующий дистрбутив, который и станет стандартом. Как произошло с Андроидом, который тоже на базе ядра Linux, но при этом имеет абсолютно однозначное системное API и соответственно крайне удобный инструмент кроссплатформенной сборки из любых других систем (Windows, Mac, Linux).
Так что да, для сборки ПО под десктопный Линух проще всего делать это в Виртуалке (если процессорная архитектура подходит), а не пытаться честно настроить нужное окружение в своей хост системе. Но во всех остальных случаях гораздо удобнее настроить нормальную кросскомпиляцию на своей любимой системе (и собственно нет никакой особой разницы что это за хост-система, т.к. для нормальных целевых систем всё удобно реализовано под все системы).
Здравствуйте, /aka/, Вы писали:
A>Вау. Расскажи, какие публичные проекты ты собирал на виндовсе под линукс?
Сейчас мы ушли на общую платформу WASM с единым "дистирибутивом" под все ОС и процессоры, так что оно стало не актуально. Но раньше у нас был нативный клиент на C++, который собирался из одних исходников в десяток разных дистрибутивов, под множество ОС (WIndows, Mac, Linux, Android, iOS) и процессорных архитектур. При этом вся разработка велась под Виндой и никаких проблем не было. Хотя да, сборка под Линух была в Виртуалке, т.к. лень было страдать. Но если бы хостом у нас был Линух, то сборка опять же была бы в в той же самой виртуалке, т.к. целевой линух для нашего ПО сильно отличался от нормального разработческого.
Здравствуйте, /aka/, Вы писали:
A>Собрать для виндовса что-то сложнее "Hello, World", если оно не написано для виндвоса, чаще всего не получается, даже если писалось оно на той же x86.
Это в полной мере относится и к обратному процессу. Если программа сделана на чистом C/C++, без выхода за границы его устоявшегося стандарта, она без проблем соберется хоть в линуксе, хоть в винде. Если программа использует конкретные средства ОС, но они полностью и корректно изолированы, она опять же соберется и там, и там. А дальше начинаются проблемы, одинаковые в обеих системах.
Но в винде, повторю, нет такого извращения, как традиция тащить все в исходниках и собирать по месту. Поэтому сборка и под хостовую винду, и под любую другую, и кросс-сборка под любую другую систему не отличаются вообще никак — нужны только необходимые средства, каждое из которых само может установить для себя нужную ему среду. В линуксе к этому добавляется еще и среда хостовой системы, которая имеет принципиальное значение, ее невозможно игнорировать без специальных приседаний. Вот эта привязка — совершенно лишняя, чистый атавизм древних времен, как продажа товаров в нагрузку. По сути, линукс как был "системой для программиста", так и остался ею, и попытки сделать из него "систему для пользователя/администратора" сильно тормозятся инерцией мышления.
A>Потому что не микрокалькулятореконтроллере нет компилятора.
Ну да, как только МК достигнут мощности, позволяющей поднимать на них компилятор, вы тут же его туда потащите — "потому, что положено".
A>Расскажи, какие публичные проекты ты собирал на виндовсе под линукс?
Не помню уже, давно последний раз с этим возился. Но хорошо помню, что почти все были заточены под эту самую "родную среду", в которой можно тупо обойтись командой make, поэтому приходилось каждый раз смотреть, что нужно проекту, и создавать для него среду.
Здравствуйте, alex_public, Вы писали:
A>>Вау. Расскажи, какие публичные проекты ты собирал на виндовсе под линукс? _>...у нас был нативный клиент на C++, который собирался из одних исходников в десяток разных дистрибутивов, под множество ОС
Выделено же — публичные проекты. Зачем лезть со своими белыми и пушистыми исходниками? У нас тоже есть наш код, который из одних исходников кросс-компилируется под разные платформы.
Сборка своего не даёт тебе никакого понимания о тех конюшнях, которые придётся разгребать, когда будешь собирать чужое, не подготовленное авторами к кросс-коспиляции.
Здравствуйте, alpha21264, Вы писали:
A>Это означает, что Линукс решает более сложные задачи. Такие задачи, за которые Виндовс даже не берётся.
Тут мы рискуем уйти в сугубый холивар, так что вряд ли стоит так обобщать. Давайте ограничимся идеологией и системами сборки.
A>Например полный набор программ для Raspberry Pi.
"Полный" — это который? Так-то под виндой на Raspberry Pi идет все, что я навскидку сумел найти для ARM64. Если надо что-то еще, и оно есть в исходниках, и не заточено специально под x86/x64 — какая проблема собрать? А если заточено, то чем ему поможет линукс?
Здравствуйте, zx zpectrum, Вы писали:
ZZ>Причём тут кросс-компиляция под микроконтроллеры из под винды
При том, что в винде принципиально нет понятия "сборка под родную систему". В ней всегда была и есть "просто сборка". Что под свою систему, что под чужую, что под линукс, что под МК — результат определяется исключительно набором и настройкой используемых средств.
ZZ>Ты ту прямую систему кросс-сборки ещё поди найди.
Прямая система сборки — это не та, где для сборки чего угодно подо что угодно достаточно ткнуть кнопку или набрать короткую команду, такую систему правильнее называть "удобной". А прямая система — та, что по возможности лишена кривизны, хотя бы искусственной.
Здравствуйте, alex_public, Вы писали:
_>Это является следствием отсутствия спецификации API для ОС
Это другая, отдельная проблема линуксов, которую нужно было решить еще много лет назад, но в обозримое время, боюсь, она решена не будет. Но сама по себе она не создает сколько-нибудь серьезных проблем для сборки.
_>из-за чего классические скрипты сборки под данные ОС начинают проверять не версию API (как делается во всех других приличных местах), а наличие каждой отдельной функции.
Да и ради бога. Только проверять все это они должны не "где-то здесь", а по вполне конкретному конфигу единого формата, на который можно явно указать. Этот конфиг должен создаваться при сборке каждой системы, более-менее документирован, чтоб его можно было хоть скопировать с целевой системы, хоть создать заново по ее описанию. И тогда сборка "где угодно подо что угодно" автоматически работала бы правильно.
_>Есть ядро Linux и сотня разных дистрибутивов на его базе, с десятками несовместимых версий
Так я в курсе. Но, раз уж образовался такой зоопарк — в чем проблема фиксировать параметры каждого из получающихся вариантов хоть в едином конфиге, хоть в наборе из нескольких, но известных конфигов? Насколько я знаю, это всегда использовалось во всех ОС, которые генерировались "по месту", с привязкой к конкретному железу и конфигурации. И только в линуксах сборочные скрипты выясняют, какие библиотеки и утилиты есть в системе, сканируя каталоги.
_>проще всего делать это в Виртуалке (если процессорная архитектура подходит), а не пытаться честно настроить нужное окружение в своей хост системе.
Не будь этой изначальной кривизны, не нужно было бы никаких "попыток честной настройки" — все сводилось бы к копированию из целевой системы одного-двух-трех конфигов. А заголовки и библиотеки всегда удобнее универсальные, из которых собираются все мыслимые варианты. На худой конец, иметь в системе одну-две-три библиотеки, которые реализуют привязку к ядру, если уж невмоготу как-то выделить универсальный промежуточный слой.
Здравствуйте, /aka/, Вы писали:
A>конюшнях, которые придётся разгребать, когда будешь собирать чужое, не подготовленное авторами к кросс-коспиляции.
Так я о том и говорю, что при адекватном подходе к компиляции нет нужды в какой-то специальной подготовке к ее кросс-варианту. Поэтому неправильно говорить о проблемах и боли кросс-компиляции, не подчеркивая каждый раз, что они характерны именно для линуксов, а не самой для кросс-компиляции, как таковой.
Здравствуйте, alpha21264, Вы писали:
A>Она там не "работает". Она там "есть". Без программ.
В том же состоянии, что и линукс после появления новых платформ. Все, что есть в исходниках под винду для x86/x64, с легкостью собирается под ARM (хоть 32, хоть 64), если оно не заточено под особенности архитектуры. Но то же самое касается и линукса. Если же в исходниках чего нет, оно и под виндой, и под линуксом появится не раньше, чем соберет разработчик.
A>Вот ровно потому что.
Ровно настолько, насколько платформа востребована. Навскидку, под ARM64 уже давно подтянули FAR, 7-Zip, утилиты SysInternals, еще что-то по мелочи. Пишут, что MS уже выкатили студию под ARM64 — с прицелом на то, чтоб разработчики ставили винду на Mac M1/M2.
ЕМ>При том, что в винде принципиально нет понятия "сборка под родную систему". В ней всегда была и есть "просто сборка". Что под свою систему, что под чужую, что под линукс, что под МК — результат определяется исключительно набором и настройкой используемых средств.
Это всё красивые концептуальные речи. А теперь пара вопросов из грязной приземлённой практики:
1. Компилятор msvc с хост-архитектурой x86_64-windows сумеет выдать статическую или динамическую библиотеку с target–архитектурой arm–linux, которую потом успешно всосёт gcc или clang под целевой ОС?
2. Какая-нибудь роутерная прошивка OpenWRT потребует под виндой менее забористых и более прямых build–скриптов по сравнению со сборкой оной под линуксом?
По-моему Вы просто основываете свои утверждения на маргинальных примерах сборки под MK, то есть под bare metal target. В этом случае все телодвижения действительно на порядок проще оных при сборке именно под чужую ОС.
Здравствуйте, /aka/, Вы писали:
A>>>Вау. Расскажи, какие публичные проекты ты собирал на виндовсе под линукс? _>>...у нас был нативный клиент на C++, который собирался из одних исходников в десяток разных дистрибутивов, под множество ОС A>Выделено же — публичные проекты. Зачем лезть со своими белыми и пушистыми исходниками? У нас тоже есть наш код, который из одних исходников кросс-компилируется под разные платформы. A>Сборка своего не даёт тебе никакого понимания о тех конюшнях, которые придётся разгребать, когда будешь собирать чужое, не подготовленное авторами к кросс-коспиляции.
Так наш проект то использовал десятки открытых библиотек, которые в начале надо собрать, опять же под все целевые платформы. И там встречалось всякое. Были и по сути не зависящие от платформы, такие как Boost (во всяком случае большая часть их библиотек). Были и нормально собирающиеся под все платформы, но ценой очень сложного кастомного скрипта сборки (такие как Qt, OpenSSL и т.п.). А были и вообще без подготовки под все платформы, так что приходилось для них самим писать универсальные (под все платформы) скрипты сборки, как например для библиотеки UDT. Так что опыта игр в эти дела более чем достаточно и происходило это всё с Windows (правда с Линуха или Мака оно всё было бы точно так же).
Здравствуйте, zx zpectrum, Вы писали:
ЕМ>>При том, что в винде принципиально нет понятия "сборка под родную систему". В ней всегда была и есть "просто сборка". Что под свою систему, что под чужую, что под линукс, что под МК — результат определяется исключительно набором и настройкой используемых средств. ZZ>Это всё красивые концептуальные речи. А теперь пара вопросов из грязной приземлённой практики: ZZ>1. Компилятор msvc с хост-архитектурой x86_64-windows сумеет выдать статическую или динамическую библиотеку с target–архитектурой arm–linux, которую потом успешно всосёт gcc или clang под целевой ОС?
MSVC — это убогое недоразумение. Я его держал у себя исключительно для целей сравнения. А так, все сборки для видны были или с помощью gcc (mingw) или clang'a, которые просто на голову лучше (правда каждый по своему). Ну и есть конечно ещё icc, но это отдельная тема для тех, кому критичен каждый такт и платформа только Intel Х86.
ZZ>2. Какая-нибудь роутерная прошивка OpenWRT потребует под виндой менее забористых и более прямых build–скриптов по сравнению со сборкой оной под линуксом?
OpenWRT — это как раз классический Linux дистрибутив и как все они является самой проблемной целевой платформой для кросс-компиляции. Я подробном писал об этом выше.
ZZ>По-моему Вы просто основываете свои утверждения на маргинальных примерах сборки под MK, то есть под bare metal target. В этом случае все телодвижения действительно на порядок проще оных при сборке именно под чужую ОС.
А скажем сборка под Android (если что, это в данный момент самая массовая ОС на планете) надеюсь не является маргинальным примером? И там кстати тоже ядро Linux... Но при этом кросс-компиляция изначально идеально продумана и работает одинаково беспроблемно на любой хост-системе.
Здравствуйте, zx zpectrum, Вы писали:
ZZ>1. Компилятор msvc с хост-архитектурой x86_64-windows сумеет выдать статическую или динамическую библиотеку с target–архитектурой arm–linux, которую потом успешно всосёт gcc или clang под целевой ОС?
Не уверен, поскольку задачи полной совместимости по библиотекам там никогда не стояло — только по исходникам. Если нужно собирать непременно библиотеки в линуксовых форматах, может оказаться проще использовать на хосте те же gcc/clang. Только какой может быть смысл в таком сочетании, кроме того, что библиотеки нужных форматов недоступны, и их исходники тоже?
ZZ>2. Какая-нибудь роутерная прошивка OpenWRT потребует под виндой менее забористых и более прямых build–скриптов по сравнению со сборкой оной под линуксом?
Вряд ли, поскольку роутерные прошивки изначально собирались только в кросс-режиме, а после того, как появились роутеры, способные собирать их локально, вряд ли кто-то заморочился с переделкой под такой режим.
ZZ>все телодвижения действительно на порядок проще оных при сборке именно под чужую ОС.
Я говорю прежде всего о том, что само по себе разделение на "свою" и "чужую" ОС является сугубо искусственным и не обосновано ничем, кроме упрямого желания "просто хочу, чтоб было так". Система разработки/сборки вообще не должна содержать таких категорий. Она должна тупо получать на входе исходники, библиотеки и параметры сборки в явном виде, тогда на выходе всегда будет предсказуемый результат, никак не зависящий от ее текущего окружения. Для удобства в ней может быть режим "взять параметры из родной системы", но это должен быть лишь один из возможных равноправных вариантов, а не стандартный и предпочтительный.
Здравствуйте, alex_public, Вы писали:
_>тоже ядро Linux... Но при этом кросс-компиляция изначально идеально продумана и работает одинаково беспроблемно на любой хост-системе.
Самое смешное, что не надо ничего "идеально продумывать". Достаточно убрать (а еще лучше — изначально не вводить) разделение на "свою" и "чужую" системы, как все проблемы совместимости исчезнут, и останутся лишь вопросы удобства — в каком виде задавать параметры, как организовать хранилище и т.п.
По сути, это же самые азы абстракции — вместо конкретного значения использовать "x", "n" и прочее. И в математике, и в программировании они всегда приветствовались. И переменные в makefile тоже были введены, чтобы уйти от конкретных значений. Странно, как при таком подходе могла появиться парадигма "собираем всегда под себя" — тем более, что в 70-е уже хватало машин, идентичных/совместимых по системе команд, но сильно различавшихся по доступным ресурсам и удобству среды. Казалось бы, идея собирать что сам unix, что софт под него, на более мощной/удобной машине, а затем переносить на целевую, должна была возникнуть автоматически.
Я в 80-е много работал на PDP-11 с RSX-11M, ее тоже нужно было "генерировать" под типы целевого процессора, набор устройств, конфигурацию ПО и т.п. Но на любой машине можно было сгенерить систему под любую другую, лишь бы она поддерживалась. Встроенных кросс-средств в той системе не было, но лишь потому, что все было написано на ассемблере, и настройка на аппаратуру обеспечивалась обычной условной трансляцией. Будь оно написано на ЯВУ, точно так же работал бы и компилятор, позволяющий задавать целевую архитектуру.
И привязка к ядру там тоже была — любой драйвер или системную утилиту нужно было транслировать с файлом системных определений, а собирать — с файлом символов от ядра, чтобы состыковать адреса. Но с тем же успехом можно было подсунуть файлы определений и символов от другой системы, а потом скопировать бинарник туда — я так делал регулярно, чтобы не ходить из зала в зал. Это было нетрудно, поскольку единой системы сборки не было, все задавалось в командной строке или в индивидуальном командном файле.
Поскольку для линуксов давно наработаны типовые комплекты скриптов, в основу которых положена странная идея "своей" системы, неудивительно, что это создает столько проблем при малейшем отступлении от привычных вариантов.
Здравствуйте, /aka/, Вы писали:
A>Сборка своего не даёт тебе никакого понимания о тех конюшнях, которые придётся разгребать, когда будешь собирать чужое, не подготовленное авторами к кросс-коспиляции.
А так уж надо ли эти конюшни разгребать? Я уже столько раз видел как оказывалось дешевле и быстрее "взорвать руины и построить сразу нормально" что у меня уже аллергия на опенсорсные копролиты.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Мне вот интересно, есть ли хоть одна надобность, не говоря уже о "еще какой". Единственное, что приходит на ум — отсутствие нормального кросс-компилятора для целевой платформы. Но такое, насколько я знаю, кончилось еще лет двадцать назад.
1. Кросс-компиляция с некоторыми зависимостями может быть проблемной, например Qt.
2. Тестирование после сборки.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Это какая-то крайне извращенная технология. Если параметрами библиотеки являются известные, фиксированные свойства целевой системы — они должны быть документированы и там, и там, и никаких сложностей с заданием значений возникать не должно.
Очевидно, параметры могут быть неизвестны, но, возможно, документированы.
ЕМ> Если же библиотеке нужна "тонкая настройка" на целевую платформу (какие-то нюансы аппаратной или программной конфигурации, производительности и т.п.), то конфигуратор должен быть сделан так, чтобы собрать его кросс-средствами было предельно просто, в идеале — в одну командную строку.
Откуда кросс-средствам знать параметры целевой платформы? Вы не забывайте, что сами кросс-средства тоже иногда собираются из исходников.
ЕМ>Ну и так заморачиваться со статической конфигурацией имеет смысл лишь в том случае, когда динамическая (при инициализации библиотеки уже на целевой платформе) обходится неоправданно дорого.
Иногда это просто не возможно.
ЕМ>То есть, проблема снова не в кросс-компиляции, как таковой, а в явной кривизне софта, ей подвергаемого.
Задача: сделать средство кросскомпиляции, которое будет работать для любых целевых архитектур, даже ещё не созданных. Как такую задачу решить?
BFE>>вам хотелось бы увидеть реальные строки из моей рабочей системы? ЕМ>Да хоть бы пути с измененными именами примерно той же длины, чтобы стало более-менее понятно — реальная там необходимость в длинных путях, или просто причуда.
/asdf/asd/qwe/asd_asdfghjklas/asdfghjklh/adadadada.aaaa.aaaaaaaaaaa/qwertyuouy/sdf/asd_werty/asd/ljutdbms/aassdfgta/xdrtyhbvfgd/ddd.sdfrdgrdg.dd/dft.sgsgsgsgsg/sss_sdfrtgddfvxcdAndhjdjdkdkdkdlAtffhjkklsbddyecetdDuringhdjdlddydbLimitdsSgfhkfifnSkfdkfjjwqwaInvariant.cpp
И это при том, что были предприняты усилия по сокращению длины имён каталогов: многие из имён каталогов были по 40-50 символов длиной, да и вложенность была поболее.
BFE>>Просто ограничение в винде накладывают естественным образом ограничения на пользователей, а вот начинаешь что-нибудь развесистое из другой системы копировать и облом. ЕМ>Вот и вопрос, отчего оно в той системе такое развесистое. Скажем, насколько часто в программах на C++ встречаются имена, полная запись которых (со всеми namespace-ами, именами классов и прочим) дотянет хотя бы до 200 символов?
Не часто, но встречается.
BFE>>Все исходники открыты, можете заняться. ЕМ>А мне оно на хрена? Я предпочитаю называть каталоги именами разумной длины, чтоб путь, по возможности, не превышал 100-120 символов.
Так я о том и говорю, никто это чинить не будет.
BFE>>Это не будут чинить по другой причине: поставил WSL и нет таких проблем. ЕМ>А по какой причине не чинили пятнадцать лет до появления WSL?
Считали извращением кросскомпилировать исходники линаксав не из под линаксов.
BFE>>попробуйте убедить какого-нибудь линуксоида устанавливать библиотеки не в систему, а домашний каталог. ЕМ>Тогда, наверное, стоило бы при обсуждении проблем с кросс-компиляцией оговаривать, что бОльшая их часть возникает от кривизны рук на разных уровнях.
Почему именно рук?
BFE>>Ну раз должны, тогда надо назначить ответственного. Есть кандидаты? ЕМ>Ну а кто там в Linux-сообществе отвечает за разработку стандартов и рекомендаций? Вот их и назначать. Не-не-не. Вам дают продукт как есть: не хотите — не пользуйте.
ЕМ>Если это делается грамотно и корректно в рамках поддерживаемых архитектур — пусть хоть к char'у приводят, но пишут в документации: "библиотека не поддерживает архитектуры, размер указателей в которых превышает sizeof (char)".
Вполне возможно, что где-то в недрах исходников, в комментарии так и написано. И что?
ЕМ>Почти в любой статье о "Unix Philosophy" упоминается о portability over efficiency. А как добиться portability без compatibility?
portability без compatibility — это легко. Это вообще ортогональные понятия.
A>Да, кстати, есть такая штука — yocto. A>https://www.yoctoproject.org/ A>Я пробовал. Оно даже работает.
buildroot проще для восприятия и тоже работает
Как много веселых ребят, и все делают велосипед...
Здравствуйте, B0FEE664, Вы писали:
BFE>/asdf/asd/qwe/asd_asdfghjklas/asdfghjklh/adadadada.aaaa.aaaaaaaaaaa/qwertyuouy/sdf/asd_werty/asd/ljutdbms/aassdfgta/xdrtyhbvfgd/ddd.sdfrdgrdg.dd/dft.sgsgsgsgsg/sss_sdfrtgddfvxcdAndhjdjdkdkdkdlAtffhjkklsbddyecetdDuringhdjdlddydbLimitdsSgfhkfifnSkfdkfjjwqwaInvariant.cpp
На винде:
C:\Windows\servicing\LCU\Package_for_RollupFix~31bf3856ad364e35~amd64~~19041.2006.1.7\amd64_microsoft-windows-fileexplorer.appxmain_31bf3856ad364e35_10.0.19041.1949_none_dde30ee0b2d6f53a\n\squaretile44x44.targetsize-256_altform-unplated_contrast-black_devicefamily-colorfulunplated.png
285 символов, даже подлиннее твоего на глаз
И это в самой винде. Так у меня и 300 символов есть в своих файлах
Здравствуйте, CreatorCray, Вы писали:
CC>На винде: CC>C:\Windows\servicing\LCU\Package_for_RollupFix~31bf3856ad364e35~amd64~~19041.2006.1.7
Так это ж чисто внутривиндовые дела, они уже больше двадцати лет не создают проблем. Он-то жалуется на то, что gcc использует ANSI-версии файловых фунций, которые не понимают больше 260. И это правильно — каждой такой функции приходится транслировать путь в Unicode, для чего выделять память в стеке. Снятие ограничения в ANSI (в котором нет никакого смысла) привело бы или к увеличению расхода стека, или к необходимости выделять динамически. Если gcc столько времени тянут на ANSI-функциях, ни длинные, ни национальные имена подавляющее большинство не парят.
Здравствуйте, Skorodum, Вы писали:
S>1. Кросс-компиляция с некоторыми зависимостями может быть проблемной, например Qt.
Как я уже объяснил, это проблема не кросс-компиляции, а линуксового подхода к ней.
S>2. Тестирование после сборки.
Это уже вообще никак не связано с местом сборки. Я свой виндовый софт тестирую в нескольких виртуалках с разными версиями винды, и на одном ноутбуке c Win 7/10, но даже в страшном сне не приходила в голову мысль взгромоздить туда средства разработки.
Здравствуйте, B0FEE664, Вы писали:
ЕМ>>Если параметрами библиотеки являются известные, фиксированные свойства целевой системы — они должны быть документированы
BFE>Очевидно, параметры могут быть неизвестны, но, возможно, документированы.
Мне, наоборот, очевидно, что сама идея библиотеки с неизвестными параметрами, которые ее сборочные скрипты втихушку извлекают из системы, в которой происходит сборка, может быть оправдана исключительно ее полной локальностью (библиотека делается только для себя, и никогда не будет распространяться сколько-нибудь широко).
BFE>Откуда кросс-средствам знать параметры целевой платформы?
В адекватных кросс-средствах все без исключения параметры сборки задаются в явном виде — в командной строке, в заголовках, в make-скриптах, в конфигах и т.п. Никаких неявных параметров, которые сборочные средства добывают из хостовой системы, трактуя ее, как целевую, там не бывает в принципе. Если бывает — значит, это не кросс-средства, а обычные средства сборки "по месту", которые лишь в силу удачного совпадения можно использовать для кросс-сборки.
BFE>Вы не забывайте, что сами кросс-средства тоже иногда собираются из исходников.
Если они собираются исключительно для использования там же, где собирались — значит, их сборка не имеет никакого отношения к "кросс"-технологиям. Если же там предусмотрена возможность сборки в одной системе (хостовой), а использования — в другой (целевой), то должна быть возможность описать целевую систему явно (в идеале — запуском в ней скрипта, который сформирует набор параметров, который можно будет передать системе сборки в готовом виде).
BFE>Задача: сделать средство кросскомпиляции, которое будет работать для любых целевых архитектур, даже ещё не созданных. Как такую задачу решить?
Она решена давным-давно: такое средство требует себе на вход всех параметров целевого окружения, которые могут иметь значение для результата компиляции. Если параметров достаточно, компиляция и сборка проходят успешно. Если каких-то параметров не хватает или они создают противоречие — компиляция аварийно завершается. Принципиально кросс-компиляция ничем не отличается от локальной компиляции — результат полностью определяется набором средств и их настройкой.
BFE>/asdf/asd/qwe/asd_asdfghjklas/asdfghjklh/adadadada.aaaa.aaaaaaaaaaa/qwertyuouy/sdf/asd_werty/asd/ljutdbms/aassdfgta/xdrtyhbvfgd/ddd.sdfrdgrdg.dd/dft.sgsgsgsgsg/sss_sdfrtgddfvxcdAndhjdjdkdkdkdlAtffhjkklsbddyecetdDuringhdjdlddydbLimitdsSgfhkfifnSkfdkfjjwqwaInvariant.cpp
Мне одному кажется, что здесь видна явная тенденция к удлинению имен сверх разумной, или еще кто-нибудь так считает?
BFE>Считали извращением кросскомпилировать исходники линаксав не из под линаксов.
Как я понимаю, до сих пор считается извращением кросс-компилировать любые линуксовые исходники вне системы, где будет работать софт (упомянутый true linux way"). А многие ли понимают, что это тупиковый путь? Чем это принципиально отличается от использования литералов вместо именованных констант, глобальных переменных вместо параметров функций и т.п?
ЕМ>>Тогда, наверное, стоило бы при обсуждении проблем с кросс-компиляцией оговаривать, что бОльшая их часть возникает от кривизны рук на разных уровнях.
BFE>Почему именно рук?
Потому, что выражение такое. Если что-то получается плохо, принято говорить о кривых руках, даже если в основе лежит кривая идея.
BFE>Вам дают продукт как есть: не хотите — не пользуйте.
А какие соображения поддерживают оставление продукта в таком состоянии?
ЕМ>>пусть хоть к char'у приводят, но пишут в документации: "библиотека не поддерживает архитектуры, размер указателей в которых превышает sizeof (char)".
BFE>Вполне возможно, что где-то в недрах исходников, в комментарии так и написано. И что?
Я б такую библиотеку использовал лишь в крайних случаях, когда без нее совсем никак. Насколько часто такое бывает? Я еще могу понять, когда такое используется "чиста у себя" — "как-то получилось, и хрен с ним". Но получается, что такие библиотеки регулярно включаются в массовые продукты, и это считается вполне нормальным.
BFE>portability без compatibility — это легко.
Compatibility — это ж не только о двоичной совместимости. Это совместимость и по идеологии, набору функций, файловым системам, ключевым утилитам, их параметрам и функциональности и прочему. Если в линуксе на какой-то платформе не будет bash'а или совместимой с ним оболочки, а все скрипты будут переписаны на другой язык — это будет еще линукс, или уже что-то другое?
Ну и сама идея portability автоматически подразумевает, что хотя бы первая сборка ядра и основного софта под новую платформу будет проходить в другой системе. Тут бы и сообразить, что описание целевой системы в явном виде должно быть правилом, а не исключением для таких случаев.
Re[2]: Raspberry Pi and programmable logic device, PLD
Здравствуйте, Евгений Музыченко, Вы писали:
BFE>>Очевидно, параметры могут быть неизвестны, но, возможно, документированы. ЕМ>Мне, наоборот, очевидно, что сама идея библиотеки с неизвестными параметрами,
Параметры известны, вручную их редактировать долго, но можно.
BFE>>Вы не забывайте, что сами кросс-средства тоже иногда собираются из исходников. ЕМ>Если они собираются исключительно для использования там же, где собирались — значит, их сборка не имеет никакого отношения к "кросс"-технологиям.
Имеет. Для кросс компиляции нужен компилятор, который умеет в эту кросскомпиляцию. А где его взять? Правильно — собрать из исходников.
ЕМ>Если же там предусмотрена возможность сборки в одной системе (хостовой), а использования — в другой (целевой), то должна быть возможность описать целевую систему явно (в идеале — запуском в ней скрипта, который сформирует набор параметров, который можно будет передать системе сборки в готовом виде).
Ну так и делается. Только вот параметров там столько, что одна поверхностная конфигурация без вникания в параметры, а только по выбору групп параметров, занимает несколько часов.
ЕМ>Принципиально кросс-компиляция ничем не отличается от локальной компиляции — результат полностью определяется набором средств и их настройкой.
Ага. Теоретически теория совпадает с практикой.
ЕМ>Мне одному кажется, что здесь видна явная тенденция к удлинению имен сверх разумной, или еще кто-нибудь так считает?
Видна, не видна, важно, что gcc такое не тянет.
ЕМ>Как я понимаю, до сих пор считается извращением кросс-компилировать любые линуксовые исходники вне системы, где будет работать софт (упомянутый true linux way"). А многие ли понимают, что это тупиковый путь? Чем это принципиально отличается от использования литералов вместо именованных констант, глобальных переменных вместо параметров функций и т.п?
Это вопрос не ко мне.
BFE>>Вам дают продукт как есть: не хотите — не пользуйте. ЕМ>А какие соображения поддерживают оставление продукта в таком состоянии?
Иногда, для заработка денег, иногда из за нехватки времени. А в целом я не знаю.
ЕМ>Я б такую библиотеку использовал лишь в крайних случаях, когда без нее совсем никак. Насколько часто такое бывает?
Зависит от политики компании. Если политика: "ничего своего не пишем, если уже можно взять написанное", то тащат всё подряд не взирая на качество кода.
Если политика: проверяем всё, так как от нашего кода зависит безопасность, то даже из C-шного стандартного printf могут выкинут функциональность вывода чисел с плавающей точкой, так как такая конвертация не однозначна и занимает много места.
ЕМ>Я еще могу понять, когда такое используется "чиста у себя" — "как-то получилось, и хрен с ним". Но получается, что такие библиотеки регулярно включаются в массовые продукты, и это считается вполне нормальным.
А вы думаете, что есть множество людей, которым нечего делать и которые сидят и пишут код за просто так? Вот что есть — то и имеем.
BFE>>portability без compatibility — это легко. ЕМ>Compatibility — это ж не только о двоичной совместимости. Это совместимость и по идеологии, набору функций, файловым системам, ключевым утилитам, их параметрам и функциональности и прочему. Если в линуксе на какой-то платформе не будет bash'а или совместимой с ним оболочки, а все скрипты будут переписаны на другой язык — это будет еще линукс, или уже что-то другое?
Конечно линукс. У bash'а есть несколько альтернатив, штук 5 или больше.
А у Windows, например, есть несколько альтернативных графических интерфейсов. И что? Это уже не Windows?
ЕМ>Ну и сама идея portability автоматически подразумевает, что хотя бы первая сборка ядра и основного софта под новую платформу будет проходить в другой системе.
Ну почему же? Человека, который ратует за то, чтобы править все параметры вручную, не затруднит прямо в кодах набивать программки. Взгляните, например, на мой никнейм. ....
ЕМ> Тут бы и сообразить, что описание целевой системы в явном виде должно быть правилом, а не исключением для таких случаев.
Опять "должно"? Я уже советовал назначить ответственного...
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Как я уже объяснил, это проблема не кросс-компиляции, а линуксового подхода к ней.
Это реальность, а не линуксовый подход
ЕМ>Это уже вообще никак не связано с местом сборки.
Это связано с тем, что для тестирования нужна целевая машина, или виртуальная или реальная. Раз инфраструктура для машины нужна по любому, сборка на целевой машине может быть значительно проще кросс-компиляции.
ЕМ>Я свой виндовый софт тестирую в нескольких виртуалках с разными версиями винды, и на одном ноутбуке c Win 7/10, но даже в страшном сне не приходила в голову мысль взгромоздить туда средства разработки.
Юнит-тестов во время сборки у тебя нет?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Особенно любопытно, как это объяснять тем, кто делает софт для микроконтроллеров Intel/PIC/AVR, для которых "нативных" компиляторов не существует в природе.
Так это многое объясняет: а) у тебя нет альтернативы б) нет сложных зависимостей (а-ля Qt c аппаратной поддержкой OpenGL).
С малиной дело обстоит иначе: во многих случаях настроить малину куда быстрее, чем настраивать кросс-компиляцию.
ЕМ>Если на практике непрозрачно, причина может быть только одна — кривая кросс-система. Других причин не бывает.
Собери на винде приложение с поддержкой OpenGL для RPi4. Уверен, что потратишь время раз в дцать больше, чем установка ОС, gcc, git, cmake, ninja и Qt на малину с нуля.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я говорю прежде всего о том, что само по себе разделение на "свою" и "чужую" ОС является сугубо искусственным и не обосновано ничем, кроме упрямого желания "просто хочу, чтоб было так". Система разработки/сборки вообще не должна содержать таких категорий. Она должна тупо получать на входе исходники, библиотеки и параметры сборки в явном виде
Это усложняют куда более типичную задачу для Линуксового мира: распространение софта в исходниках. Классическое "configure && make && make install" как тогда будет работать?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Тогда получается, что средства кросс-компиляции и проекты для недокомпьютеров сделаны лучше, чем для "полноценных".
Почему это смех вызывает? Для МК других решение просто нет В то время как малина — это полноценный ПК. Да и со средствами кросс-компиляции проблем-то нет, есть сложности со сборкой сложных проектов, но это глупо сравнивать с софтом для МК.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Мне интересно, за счет чего может быть реально удобнее что-то собирать в системе, с которой не работаешь сколько-нибудь регулярно, в которой не настроена комфортная для этого среда.
Вот это показательный момент. Нормально организованная сборка автоматизирована и более-менее одинакова на всех целевых платформах. Упоминать "комфорт" тут вообще не уместно.
З.Ы. Под малину мы используем и нативную и кросс-компиляцию.
ЕМ>Я говорю прежде всего о том, что само по себе разделение на "свою" и "чужую" ОС является сугубо искусственным и не обосновано ничем, кроме упрямого желания "просто хочу, чтоб было так". Система разработки/сборки вообще не должна содержать таких категорий. Она должна тупо получать на входе исходники, библиотеки и параметры сборки в явном виде, тогда на выходе всегда будет предсказуемый результат, никак не зависящий от ее текущего окружения. Для удобства в ней может быть режим "взять параметры из родной системы", но это должен быть лишь один из возможных равноправных вариантов, а не стандартный и предпочтительный.
Да, желание-то хорошее, но в силу исторических причин не срослось-с. Правильные подвижки в этом направлении демонстрирует zigcc, умеющий при работе в режиме C–компилятора без лишних танцев с бубнами генерировать бинарники под все доступные для clang целевые платформы. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html
Здравствуйте, B0FEE664, Вы писали:
ЕМ>>Мне одному кажется, что здесь видна явная тенденция к удлинению имен сверх разумной, или еще кто-нибудь так считает? BFE>Видна, не видна, важно, что gcc такое не тянет.
Звучит как баг, не?
BFE>А у Windows, например, есть несколько альтернативных графических интерфейсов.
И как мне в 10й винде включить интерфейс от 7й?
Или ты всё таки про графические API?
Здравствуйте, CreatorCray, Вы писали:
ЕМ>>>Мне одному кажется, что здесь видна явная тенденция к удлинению имен сверх разумной, или еще кто-нибудь так считает? BFE>>Видна, не видна, важно, что gcc такое не тянет. CC>Звучит как баг, не?
Как баг, который никто не будет править.
BFE>>А у Windows, например, есть несколько альтернативных графических интерфейсов. CC>И как мне в 10й винде включить интерфейс от 7й?
Например: http://www.classicshell.net/ ведущий на https://github.com/Open-Shell/Open-Shell-Menu
Я на десятке не пробовал, так как десятка у меня только от конторы, а добиться от конторы права на установку стороннего ПО — сложная процедура.
На семёрке — работает.
CC>Или ты всё таки про графические API?
Говорят, что на десятке API поменяли и поддержка сторонних оболочек стала сложнее, но как на самом деле — не знаю.
ЕМ>Поскольку для линуксов давно наработаны типовые комплекты скриптов, в основу которых положена странная идея "своей" системы, неудивительно, что это создает столько проблем при малейшем отступлении от привычных вариантов.
По сути-то необходимо соблюсти всего лишь два нюанса:
1. gcc/clang тащит с собой кодогенерацию под все известные триплеты "аритектура-ос-libc";
2. gcc/clang не имеет никаких умолчаний: всё надо передавать явно. Каждый define, каждый путь к директориям с заголовочными файлами и библиотеками, каждый флаг компиляции.
Однако, подобный тулчейн будет ломать все исторически сложившиеся практики, и по-моему именно поэтому никогда не станет стандартным.
PS. Припоминается один грязный трюк для сборки исполняемого бинарника с покрытием как можно большего количества linux'ов: статическая линковка с musl libc. Бинарь сразу перестаёт зависеть от версии glibc, чем печально славится большинство дистрибутивов: соберешь под одну версию, а под другой отваливается. Однако, под некоторыми дистрами, нарушающими кое-какие древние неписанные конвенции размещения системных файлов в фиксированных локациях на ФС (например, /etc/hosts всегда лежит по пути /etc/hosts), этот трюк тоже хрен поможет
Здравствуйте, zx zpectrum, Вы писали:
ZZ>PS. Припоминается один грязный трюк для сборки исполняемого бинарника с покрытием как можно большего количества linux'ов: статическая линковка с musl libc. Бинарь сразу перестаёт зависеть от версии glibc, чем печально славится большинство дистрибутивов: соберешь под одну версию, а под другой отваливается.
Собираешь под самую старую и всё, разве нет?
ZZ>Однако, под некоторыми дистрами, нарушающими кое-какие древние неписанные конвенции размещения системных файлов в фиксированных локациях на ФС (например, /etc/hosts всегда лежит по пути /etc/hosts), этот трюк тоже хрен поможет
Здравствуйте, B0FEE664, Вы писали:
CC>>Звучит как баг, не? BFE>Как баг, который никто не будет править.
Пусть страдают тогда
CC>>И как мне в 10й винде включить интерфейс от 7й? BFE>Например: http://www.classicshell.net/ ведущий на https://github.com/Open-Shell/Open-Shell-Menu
Не, это всего то меню и окошко эксплорера. Сам им пользуюсь. Весь остальной интерфейс всё равно от 10ки со всеми его недостатками.
BFE>На семёрке — работает.
На сеиёрке и так интерфейс от семёрки.
ZZ>1. gcc/clang тащит с собой кодогенерацию под все известные триплеты "аритектура-ос-libc";
Так clang примерно так и делает.
Например если взять Android NDK.
Там куча x86_64-linux-android28-clang, i686-linux-android29-clang,
armv7a-linux-androideabi31-clang++, aarch64-linux-android29-clang++.
То есть как бы компиляторы для разных двоек: архитектура процессора + ABI Android.
Но на самом деле все эти бинарники это скрипты для вызова "clang/clang++" с нужными аргументами.
То есть для x86_64,i686,armv7a,aarch64 и так далее собирает один clang, в коготорого все это зашито.
llvm на котором основан clang сразу из коробки может собрать под любую поддерживаемую архитектуру,
проблема только в наличие для целевой архитектуры ассебмелера, линковщика (эту проблемы llvm тоже почти решили своим линковщиком(lld))
и runtime.
vsb>Есть дистрибутивы без /etc/hosts?
Clear Linux, например. hosts лежит по пути /usr/share/default/etc/hosts.
У дистрибутива центральная идея — детерминированность, разделение на чистое/грязное, иммутабельность "чистых" мест. Подход весьма интересный с точки зрения долговременной стабильности при обновлениях, а также для облегчения поддержки и сопровождения. Пишешь на форуме, например: прилетело обновление 35810, имеются такие-то проблемы. По номеру релиза состояние системных файлов однозначным образом определяется. Конвенциональность, однако, ломается, ничего не поделаешь.
Здравствуйте, zx zpectrum, Вы писали:
ZZ>По сути-то необходимо соблюсти всего лишь два нюанса:
ZZ>1. gcc/clang тащит с собой кодогенерацию под все известные триплеты "аритектура-ос-libc";
Clang (а точнее llvm) так и работает вообще то. Ну а в gcc в принципе тоже можно организовать что-то подобное — там единственное отличие в том что традиционно плодят отдельные бинарники (да ещё и распространяемые отдельно) со своим именем под каждый триплет. Но можно накачать все нужные в одну папку и сделать простейший скриптик в несколько строк, который будет выбирать нужный по параметру.
ZZ>2. gcc/clang не имеет никаких умолчаний: всё надо передавать явно. Каждый define, каждый путь к директориям с заголовочными файлами и библиотеками, каждый флаг компиляции.
Да вообще то так по сути и работает. Если передашь путь через -I или -L, то в начале все файлы будут искаться именно там. И любой макрос можно предопределить через -D.
Так что в принципе к компиляторам на самом деле нет особых вопросов, они готовы к любым раскладам. Не готовы авторы библиотек и главное авторы скриптов сборки...
ZZ>Однако, подобный тулчейн будет ломать все исторически сложившиеся практики, и по-моему именно поэтому никогда не станет стандартным.
Именно, боюсь эта проблема для C/C++ никогда не будет решена из-за инерции. Но меня это совсем не беспокоит, т.к. на замену C++ уже пришёл Rust (который кстати с помощью LLVM компилирует). А в нём правильные практики организации сборки были заложены изначально, так что сейчас уже стали нормой для сообщества.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Да и ради бога. Только проверять все это они должны не "где-то здесь", а по вполне конкретному конфигу единого формата, на который можно явно указать. Этот конфиг должен создаваться при сборке каждой системы, более-менее документирован, чтоб его можно было хоть скопировать с целевой системы, хоть создать заново по ее описанию. И тогда сборка "где угодно подо что угодно" автоматически работала бы правильно.
Подход известен уже лет 25. Почему-то повторять его не хотят. Ленивые какие-то...
_>>Есть ядро Linux и сотня разных дистрибутивов на его базе, с десятками несовместимых версий
ЕМ>Так я в курсе. Но, раз уж образовался такой зоопарк — в чем проблема фиксировать параметры каждого из получающихся вариантов хоть в едином конфиге, хоть в наборе из нескольких, но известных конфигов? Насколько я знаю, это всегда использовалось во всех ОС, которые генерировались "по месту", с привязкой к конкретному железу и конфигурации. И только в линуксах сборочные скрипты выясняют, какие библиотеки и утилиты есть в системе, сканируя каталоги.
1) Ничто не мешает вызывать условный ./configure с пачкой --with-xxx/--without-xxx/etc. (что постоянно и делают авторы, но не исходных софтин, а инструкций пакетирования в дистрибутиве)
2) Ты представляешь себе коммуникацию между авторами, условно, 10 основных дистрибутивов и 20000+ включённых в них программ, часть которых (авторов) просто не в курсе, что на основе их продукта есть пакет в каком-нибудь PolarZooLinux?
Я — нет.
А там, где требуются существенные допилы, часто и пишут в апстрим "вы тут что-то слишком сложное написали, оно так работать не будет".
Autotools с автодетектом не зря придумали, они как раз по сравнению с описанным подходом, как в sendmail и прочих ровесниках, дали огромный шаг вперёд по облегчению суммарного труда.
ЕМ>Не будь этой изначальной кривизны, не нужно было бы никаких "попыток честной настройки" — все сводилось бы к копированию из целевой системы одного-двух-трех конфигов. А заголовки и библиотеки всегда удобнее универсальные, из которых собираются все мыслимые варианты. На худой конец, иметь в системе одну-две-три библиотеки, которые реализуют привязку к ядру, если уж невмоготу как-то выделить универсальный промежуточный слой.
Проблема в том, что той специфики от общего кода слишком мало, чтобы из-за неё заморачиваться такой прослойкой...
Здравствуйте, Евгений Музыченко, Вы писали:
BFE>>Откуда кросс-средствам знать параметры целевой платформы?
ЕМ>В адекватных кросс-средствах все без исключения параметры сборки задаются в явном виде — в командной строке, в заголовках, в make-скриптах, в конфигах и т.п. Никаких неявных параметров, которые сборочные средства добывают из хостовой системы, трактуя ее, как целевую, там не бывает в принципе. Если бывает — значит, это не кросс-средства, а обычные средства сборки "по месту", которые лишь в силу удачного совпадения можно использовать для кросс-сборки.
Вменяемые пользователи таких систем (неважно, autotools, CMake, что угодно) так и делают. Любой параметр можно задать через подобный входной конфиг, а если нет — тогда оно начинает искать само.
Если речь про вариант глобального выключения автопоиска — я где-то такое видел (возможно, и в CMake, но не в autotools). Да, это полезно для проверки самой обстановки...
Хотя, я читал, если в autotools задать кросс-компиляцию ключами даже в ту же среду, что хостовая — так и будет. (Если не сломали. Мне влом проверять.)
ЕМ>Как я понимаю, до сих пор считается извращением кросс-компилировать любые линуксовые исходники вне системы, где будет работать софт (упомянутый true linux way").
Не извращением напрямую. А лишней работой там, где можно сделать проще.
Но если видят в этом реальный смысл — делают.
Пример с малинкой как раз из этой серии.
Или у меня сейчас проект с целевой ARM (обеих разрядностей) и хостовой x86. Успешно собирается и работает. Проблемы, конечно, есть, но не от того, что кросс-компиляция, а от других вещей (например, ради комбинирования слоёв логики апстрима и местных доточек в Yocto такое навернули, что местами вешаться хочется).
ЕМ>Compatibility — это ж не только о двоичной совместимости. Это совместимость и по идеологии, набору функций, файловым системам, ключевым утилитам, их параметрам и функциональности и прочему. Если в линуксе на какой-то платформе не будет bash'а или совместимой с ним оболочки, а все скрипты будут переписаны на другой язык — это будет еще линукс, или уже что-то другое?
Сейчас до чёрта линуксов без bash или где /bin/sh не bash. Как раз с таким вожусь.
Тут ещё веселее — мы это, конечно, прямой задачей не ставили, но двое коллег уже обломались с тем, что Yocto не ставит полный less, а вместо его втыкает busyboxʼовский. Вот тут сложнее, чем все проблемы с кросс-компиляцией: выпутаться из его конструкции layerʼов.
ЕМ>Ну и сама идея portability автоматически подразумевает, что хотя бы первая сборка ядра и основного софта под новую платформу будет проходить в другой системе. Тут бы и сообразить, что описание целевой системы в явном виде должно быть правилом, а не исключением для таких случаев.
Для средств сборки и минимального обеспечения вокруг них. А дальше — как легче.
Единственное, что приходит на ум — отсутствие нормального кросс-компилятора для целевой платформы. Но такое, насколько я знаю, кончилось еще лет двадцать назад.
