Это же замечательно — много небольших по размеру модулей с максимально ослабленными между собой связями. Используем только то что нужно и не переплачиваем объемами за удобства.
Хочу добавить, что если вам принципиально не важен вебкит, то лучше добавить к init-repository еще и ключ --no-webkit, таким образом вы избавите себя от длительного ожидания «когда же эта жирная зараза скачается» и от вопросов типа «почему же эта жирная зараза не собирается».
эээ, где они имеются? в репе? там только сорцы. Как хотите так и собирайте (хотя не уверен что статический линковка сейчас работает). Или вы хотите чтобы стат. линковка работала без сборки стат. библиотек? Так не бывает, все равно собрать то надо в начале.
Правда смысла в статике (если не идет борьба за объем на жестком диске) я особого не вижу.
Ну во-первых по этой ссылке Qt4, а обсуждение идет про Qt5 (для которого нет бинарей прекомпиленных, вернее есть, но неофициальные).
Во-вторых, статическая линковка вещь неоднозначная и никто до сих пор особо не понял можно ли статик линковку использовать с lgpl (явно это не запрещается, но некоторые юристы говорят что прикопаться можно).
В-третьих, используя статик линковку мы лишаем себя удовольствия плагинов. Их надо вкомпиливать туда же и не все плагины это поддерживают. А из тех что поддерживают непонятно какие нужны конкретному юзеру, а какие нет. То есть либо делать 100500 прекомпиленных сборок (со всеми возможными комбинациями плагинов), либо делать одну боооольшую.
В-четвертых, Qt5 завязан на декларатив, который в свою очередь завязан на qml-плагины, которые насколько мне известно не поддерживают статик линковку (сам правда не пробовал так извращаться).
qml в принципе можно статически слинковывать, но только через большую жопу :)
Статическая линковка имеет смысл на платформах, где без неё не пускают в маркет(я про iOS). На винде в ней смысла НЕТ!
ну я в основном про них и говорил, когда говорил про qml-плагины. В них по сути вся соль использования qml.
А so файл в ресурсах скорее всего не подцепится, хотя я такое не пробовал
да это ж не порт, это так, баловство. Там даже в ридми написано:
This is a proof-of-concept implemenation of a UIKit based QPA plugin. Note that this is completely unsupported, and it is probable that many parts of QtCore and other Qt Modules don't work properly. There have no tests been run whatsoever.
Я всё же имел ввиду не сам порт, а именно возможность статической линковки. И таки да, Qt именно что собирается статически, это можно увидеть в ридми, на 25-й строке, там, где передаются ключи конфигурации сборки, один из них "-static", следовательно линкуется статически. А также мы видели демки запущенных на ios qml-приложений, которые по крайней мере используют плагины поддержки различных форматов изображений. Вывод — под iOS можно собирать статические приложения вместе с плагинами. Другой вывод — скорее всего нельзя отлаживать/использовать файлы qmldir (скорее всегоне будут импортироваться необходимые креатору данные для отладки, да и из креатора собрать приложения врядли можно...), а значит под iOS можно только собирать готовое и отлаженное под другие платформы приложения.
я надеюсь что у разрабов еще остался здравый смысл. Плюс гложут меня сомнения. По идее лоадер при чтении qmldir грузит либу либо из текущей+пафы, либо из прописанного в qmldir файла. Как тут быть со статиком — хз.
В любом случае, я верю в здравый смысл :D
Вообще т мне для создания инсталлера нужно) Да, знаю, что есть специальные инсталляторы вроде Inno Setup-ов и прочего, но мне слишком уж кастомный инсталлер нужен.
ну если хобби, то наверно опен сорс? если опен сорс, то битрок — бесплатен (для этого надо на сайте найти куда им по этому поводу писать и написать письмо — пришлют лицензию)
Ага, полностью анимированные кастомные кнопки, кастомный вид полей ввода, чекбоксов, скроллбоксов, прогресс баров, бекграундная музыка… Какой нить инсталлер все это умеет, причем так же просто, как я все это сделаю в qt? Мне проще статически слинковать экзешник с qt чем мучать свой мозг с костылями для всего этого для других инсталлеров.
Это вообще реврайт инсталлера, который изначально вовсе с помощью DirectDraw делался.
По поводу вебкита и его великолепной сборки. Самый оптимальный вариант это действительно забирать без вебкита (ключиком к init-repository). Сам вебкит не большой, а вот его экзамплы — мама не горюй. Вообщем и весит много и фиг соберешь новыми компилерами. После сборки кьюта без вебкита (кстати судя по всему опция --no-webkit при скачанном вебкит-модуле не работает и все равно пытается собрать) можно собрать вебкит из гита (вот тут неплохие рекомендации — wiki.qt-project.org/PhoneGap_for_Qt_5), который будет очень хорошо работать, да еще и радовать нас webkit2-фичами.
А, еще из мелочей. Вместо такого префикса проще указать --developer-build (которому не нужен make install). Ну и с относительно недавнего времени заработал наконец-то нормальный префикс (у меня сейчас кьют спокойно живет в папке /usr/local/Trolltech/Qt-5.0.0, что раньше было близко к невозможному). Правда не уверен что shadow-build починили. Он тоже был недоступен раньше, но с тех пор я им не интересовался.
Наверное, для того, чтобы можно было сделать бинарники, работающие и с X11, и с Wayland. При выполнении определяется только «оконная система» (Q_WS_...), а ОС (Q_OS_...), как и раньше, при компиляции.
А я вот хочу, чтобы при запуске через VNC или какой-то убер сетевой протокол использовалась другая оконная система, а не Q_WS_WAYLAND или Q_WS_X11, что мне делать?
Скачать из git без веба не получится таким макаром:
perl init-repository --no-webkit
Теперь нужно писать
perl init-repository --module-subset=default,-qtwebengine
А давайте пощупаем Qt5