Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Дабы соответствовать.
ЕМ>Помнится, когда-то давно знакомая в разговоре упомянула, что у нее подросла собака, ей "пора купировать уши". На мой вопрос, зачем это нужно, ответила "чтобы соответствовала породе". Следующие полчаса я старательно пытался выяснить, зачем она собирается уродовать животину, но та лишь твердила "мне объяснили, что это требуется для соответствия породе". Тогда эта дама сильно упала в моих глазах.
ЕМ>Позже я где-то прочитал, что та порода была выведена искусственно, и с ушами у этих собак часто возникали проблемы, отчего их и старались подрезать заранее. Но дама в это не вникала, и просто собиралась тупо исполнить то, что ей сообщили то ли в ветеринарке, то ли в собачьем клубе.
И что характерно — дама оказалась права, несмотря на то, что не понимала, что творила (и почему).
Вот так и у нас 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>конюшнях, которые придётся разгребать, когда будешь собирать чужое, не подготовленное авторами к кросс-коспиляции.
Так я о том и говорю, что при адекватном подходе к компиляции нет нужды в какой-то специальной подготовке к ее кросс-варианту. Поэтому неправильно говорить о проблемах и боли кросс-компиляции, не подчеркивая каждый раз, что они характерны именно для линуксов, а не самой для кросс-компиляции, как таковой.
