Комментарии 20
На этот случай можно завести bash-скрипт, который будет разворачивать всю среду в заданной папке. И после пытаться поддерживать этот скрипт в актуальном состоянии. Но, как и документация к проекту, в один критически важный момент он может устареть.
Хорошим решением будет изолировать нашу среду для сборки внутри docker-контейнера.
Использование докера не отменяет возможность устаревания. Докер не про автоматизацию, а про изоляцию и единство окружения. В докер файле придется писать все те же строки из bash скрипта.
Необходимо сделать пояснение о назначении bash-скрипта в примере. Он разворачивает среду для сборки приложения, ставит нужные библиотеки и пр. Далее, в процессе разработки, программист устанавливает необходимые компоненты в уже развернутой среде и добавляет команды в указанный bash-скрипт. Забытая зависимость всплывет при повторном разворачивании всей среды.
docker-файл содержит аналогичные команды скрипту bash, но в отличии от него используется намного чаще, как минимум для сборки каждого релиза. Соответственно, пропущенная зависимость будет выявлена гораздо быстрее в этом случае.
Почему чаще?
В моем примере предполагается, что среда разворачивается скриптом на локальном хосте для сборки релиза. А дальше, все дальнейшие изменения в среду вносятся руками, не скриптом. Т.е. в дальнейшей сборке приложения данный скрипт не участвует.
Можно было бы описать более интеллектуальный скрипт, который запускается при сборке, обновляет зависимости, удаляет все лишнее, но тогда пришлось бы менять название статьи.
Но процесс сборки производился на выделенном сервере с использованием скриптов.
А как это выглядело? Скрипт устанавливает необходимые библиотеки или просто запускает сборку? Просто у нас в компании так же используется сборка на выделенном сервере, но make-скрипты просто запускают саму сборку. Предполагается, что все зависимости уже были установлены заранее.
Зачем уж вы так сразу учите людей плохому тону, когда человечество вовсю бороздит просторы космоса переходит на 64-битную архитектуру везде где только можно, а вы тут Qt под 32 бита собираете.
Потом на убунту половина интернета ругается, что они убирают 32-битные зависимости из репозиториев. А разруха не в дистрибутивах, она в головах.
Вы совершенно правы. В туториале лучше убрать упоминание 32-битной архитектуры.
Однако, хочу отметить, что сборка приложения под такую архитектуру делает возможным запуск продукта на большем количестве ПК.
Насколько большем? А то это как вилами по воде.
Сейчас новые устройства (с Windows в частности, а Linux/Mac и подавно) с 32 битными ОС найти очень сложно, а процессоры без поддержки 64 бит и подавно. Даже Android/iOS последние годы имеют тенденцию перехода на ARM64.
Если и найти, то будут ли адекватно и с достаточным уровнем оптимизации работать в такой среде современные приложения — тоже вопрос, конечно. Это не значит, что современные приложения пишутся абы как (что порой верно), просто наборы 64-битных инструкций дают больший простор для оптимизации даже на этапе компиляции. Разработчики крупных пакетов программ тоже постепенно отказываются от поддержки.
Не спорю конечно, есть тонкости, есть легаси которое переписать нельзя/сложно, есть конторы (преимущественно государственные), где целевые машины на 32 битных виндах, но в таких случаях и с докером проблемы вероятно будут.
Суть в том, что новые приложения так точно писать не стоит, потому что зачем? Достаточный уровень проверки обеспечить как минимум трудно ввиду того что систему такую найти сложно и нужно в 2 раза больше времени на это потратить, а целевая аудитория исчезающе мала зачастую.
Для поддержания актуальности скриптов хорошо использовать git/hg/… Для изоляции достаточно chroot.
MinGW — это компилятор который создаёт код для платформы Windows и который работает под управлением Windows. Так что это плохой пример кросс-компилятора.
Сам лично учавствовал в проекте mingw-builds под руководством товарища niXman. Это набор скриптов который собирал компилятор MinGW в ОС Windows.
То, о чём пишете вы и автор статьи называется MinGW Cross-compiler, по сути, это просто GCC Cross-compiler, только target у первого всегда mingw32.
Сама расшифровка абривиатуры MinGW говорит о том что он работает в ОС Windows.
Название компилятора MinGW который хостится не на ОС Windows — некорректно. Опять же, это просто GCC Cross-compiler.
В статье была допущена ошибка в имени кросс-компилятора. Правильное название — mingw-w64
qmake && make -j $(nproc)Ссылка на GitHub
Кросс-компиляция в docker. Почему бы и нет?