Comments 28
Суровая реальность: пользователю нужно всего три программы, но они требуют десяти разных библиотек (разных версий).
Фактическая реализация: собираем каждую программу статически со всеми библиотеками
Сейчас уже не нужна платная лицензия для статической линковки?
При статической линковке платная лицензия никогда не была нужна. Вы должны предоставить пользователям возможность слинковаться с собственной версией Qt а так же предоставить все изменения которые вы внесли в Qt.
То есть либо открыть исходники либо дать объектные файлы для самостоятельной линковки.
cdn2.hubspot.net/hubfs/149513/India%20Marketing%20Assets/webinar%20recording/202005-Qt%20Virtual%20Tech%20Conf_Qt%20Licensing%20Explained.pdf
Потому что QtCreator это отдельный продукт, вероятно отдельная команда и в принципе вариант с MinGW только один из списка. А если я сперва поставил Creator и Qt SDK с MS run-time, а потом доустановил вариант с MinGW стоит ли мне устанавливать вторую версию Creator?
Ну как отдельный, если инсталяшка одна)Отдельный, и скачать его и установить можно совершенно отдельно от остального Qt SDK, или вообще собрать из исходников самому слинковав с любой поддерживаемой версией Qt, хоть и с MinGW если хочется.
github.com/qt-creator/qt-creator
и релизы
github.com/qt-creator/qt-creator/releases/tag/v4.14.1
вот и релиз слинкованый с библиотеками MinGW
github.com/qt-creator/qt-creator/releases/download/v4.14.1/qtcreator-Windows-MinGW-595990519.7z
Кто сказал, что в студии всё вместе? То, что студия скрыто устанавливает vcredist до актуальной версии не делает её примером для подражания.
Ещё раз отвечаю - QtSDK и QtCreator два разных продукта, почему они должны быть слинкованы друг с другом? Если разработчик сперва скачал QtSDK для сборки с MSVC, должен ли он устанавливать версию QtCreator с MinGW библиотеками? А если позже тот же разработчик решил переключить свой SDK на вариант собранный с MinGW надо ли перезакачивать и переустанавливать весь QtCreator? Создатели SDK сделали простое решение, выбрали самый распространённый вариант (и это не MinGW) в качестве основного, не вижу проблемы.
Ну и у меня, к примеру этой проблемы и нет, так я использую один из Линксов и, соответственно, создатели дистрибутива позаботились о том, что бы в системе был один и единственный пакет Qt и для разработки и для QtCreator и для всех приложений.
Не ну на пользователей то плевать, у них SSD то резиновые.
Цена носителя много ниже чем цена на разработку в любом случае. Плюс dll-hell существует в Windows с момента её появления. Студия страдает ровно такой же болезнью, ради интереса посмотрите сколько в системе установлено vcredist, условно 16.10 устанавливает свой ран-тайм и больше не использует ран-тайм от 16.9[.5] и так далее. Ровно как и ни одно другое приложение в системе. Может не вот прямо для каждой версии, но примерно так. Если откроете Program Files или WinSxS, то можно найти, что каждое приложение таскает с собой свой собственный набор msvcp140.dll vcruntime140.dll или старее, например msvcp71.dll и так для каждой версии и каждого патча/обновления студии, потому что бинарники от, скажем, VS2015 не совместимы с бинарниками от VS2015SP1.
Не нравится - переходите на Linux, там проблема решена кардинально, но тогда разработка будет под версию из дистрибутива 5.14.2, вместо 6.0.0, скажем.
Если пишите или используете плагины для QtCreator, то логично
А разве я про плагины говорил?
Скачали online-installer и установили QtSDK в минимуме, не выбрав ни одно пакета с Qt, только QtCreator. Вопрос - с каким run-time следует установить QtCreator? ОК, решили установить пакет 6.0.0 с VS run-time, QtCreator тоже слинкован с этим run-time, отлично, экономия места на SSD. Но через два дня стало ясно, что этот пакет не устраивает, нужен собранный MinGW с другим run-time. Удалили уже скачанный пакет, установили Qt 6.0.0 MinGW. Следует ли полностью перезакачивать QtCreator для уменьшения дублирования библиотек? А если пакет с VS run-time не удалили, а MinGW поставили параллельно? Какую версию QtCreator должен скачать установщик? Обе или какую-то одну, какую? Кто будет разрабатывать, тестировать и поддерживать всё эту логику?
Вот и получается, что самое простое и эффективное решение - устанавливать независимые пакеты со своими наборами библиотек, пусть и с дублирование на "не резиновые SSD". А если кто-то заморачивается по поводу библиотек и места - всегда можно скачать пакеты руками из официальных репозиториев, а не использовать автоматизированные средства.
не очень понимаю про пакеты Qt, и что такое QtSDK в минимуме)
см.скриншот ниже, если я удалю Qt 5.15.1 у меня останется установлен только QtCreator
Я устанавливаю qt5 под какой конкретный компилятор, и хочу чтобы QtCreator тоже был скомпилен им же.
ОК, смотрим скриншот
Я могу установить Qt версий 6.1.1, 6.04, 5.15.2, 5.14.2 и 5.9.9 С какой версией должен быть слинкован QtCreator? Предположим вы скажете с 6.1.1, ОК, но завтра я решу обновить эту версию до 6.1.2 или вообще удалить. Что должен сделать инсталятор? Переустановить QtCreator только из-за того, что изменился пакет Qt SDK?
Для поддержки этого нужна инфраструктура и DevOps.
Если у меня установлена Qt 5.15.1 то, согласно предлагаемому вами варианту QtCreator должен быть слинкован с этой версией что бы избежать дублирования библиотек. Теперь я обновляюсь до 5.15.2 и, значит, нужно обновить QtCreator. Установщик должен проверить конфигурацию, удалить устаревшее и поставить новое.
Если я захочу поставить ещё и 6.0.4, как должен поступить установщик? Установить QtCreator слинкованный с версией 6.0.4 (вариант MS vs MinGW пока вообще не будем рассматривать) или оставить 5.15.2?
А если я установлю ещё и 6.1.1 то какую версию QtCreator нужно выбрать?
Предположим установщик решил ни чего не менять, а оставить как есть. Но завтра я захочу удалить 5.х и оставить только 6.х, какую версию QtCreator должен использовать установщик? Для 6.0.4 или для 6.1.1?
Вся эта логика — это отдельная разработка, отдельные тестовые сценарии и инфраструктура поддержки.
Только для того, что бы «спасти» на SSD разработчика пару сотен мегабайт.
А в варианте с отдельным продуктом QtCreator, слинкованным с единственным вариантом Qt жертвуя 100-200 МБ дискового пространства можно исключить все эти 36 вариантов тестирования и дистрибуции и сосредоточиться только на одном повышая конечное качество продукта. Можно исключить усложнение логики инсталятора, и уже её тестирования.
Все варианты предусматривают участие высокооплачиваемых специалистов — программисты и DevOps, их средняя зарплата 40-50 долларов в час, то есть стоимость 500Gb SSD за каждый час работы.
Путь установки Qt неважен, у меня он установлен на диске D. <...> Переходите в директорию, где папка Src (D:\Qt\5.x.x\Src);
Путь установки Qt не важен (раздельно), если вы пишете статью-самопрезентацию в духе "Йо, парни! Посмотрите, как же я крут, я забацал у себя статическую линковку на Qt". А если вы пишете пошаговый туториал, которым предполагается пользоваться читателям, ранее незнакомым с процессом, то путь лучше бы указывать тот, который задаёт установщик Qt по умолчанию. И по умолчанию путь к папке Src не "C:\Qt\Qt5.x.x\Src", а "C:\Qt\Qt5.x.x\5.x.x\Src".
Введите в командную строку MinGW поочередно следующие команды:
set LANG=en
set QT_INSTALL_PREFIX="C:\Qt\5.8-static\mingw53_32"
cd /d %QT_INSTALL_PREFIX%\..\Src
В статье, на которую вы ссылаетесь (Всё в одном exe без зависимостей (статическая линковка в Qt 5.3.2)) перед вводом этих команд предписывается сделать следующее: "Создать пустую папку для статической сборки (C:Qt5.3static). В принципе, она может быть где угодно, главное чтобы была пустая. Создать в ней файл make.bat с таким содержанием...". Если это не сделано, выполнение команд, указанных вами закономерно приведёт к ошибке "Системе не удаётся найти указанный путь".
Далее вы предлагаете выполнить команду:
configure.bat -static -debug-and-release -platform win32-g++ -prefix %QT_INSTALL_PREFIX% -qt-zlib -qt-pcre -qt-libpng -qt-libjpeg -qt-freetype -opengl desktop -opensource -confirm-license -make libs -nomake tools -nomake examples -nomake tests -qt-sqlite -no-ssl
То есть файл configure.bat, по логике написания команд должен лежать по пути
C:\Qt\5.8-static\mingw53_32\Src\.
Однако перед этим вы указали
3. Папку Src копируйте в папку static. Получится D:\Qt\5.x.x\static\Src.
<...>
4. Создайте папку mingwXX_32 (у меня, например, mingw73_32).
Получится D:\Qt\5.x.x\static\mingwXX_32
То есть папка Src лежит не в папке mingwXX_32, а рядом с mingwXX_32. А затем вы "запускаете" configure.bat из C:\Qt\5.8-static\mingw53_32\Src\.
Крайне неприятно, когда на месте чёткого и выверенного туториала, написанного для решения насущной проблемы, оказывается артхаусное произведение, в котором читатель по едва уловимым отсылкам, аллюзиям и метафорам пытается понять, что же хотел сказать автор.
Причём я не пойму, в чём секрет статей именно про статическую линковку Qt. В вашей статье вам было лень заморочиться с проверкой путей, в статье, на которую вы ссылаетесь куда-то исчезли все слеши из всех путей, вот здесь предлагается всё делать по-живому, без копирования папки Src. Любопытный феномен.
Статическая линковка Qt 5.x.x с MinGW32 в Windows (сборка в один exe'шник)