Russian Qt Forum

Добрый день

"Без зависимостей" означает что никакой инсталлятор не требуется, пользователь может свободно копировать с одной машины на другую. Копироваться может файл или папка/мамка, т.е, линковать статически необязательно.

Windows: однозначно, проще (и IMHO правильней) без зависимостей, скопировал папку и все. Install также не возбраняется, но тоже без зависимостей, то есть все либы с собой.
*NIX: install only - репозитарий, deb, rpm...

Стараемся собирать под винду без зависимостей, насколько это возможно.
Обычно даже работает :)

Хочется, но зачастую не нужна :)
Хотя все итак понимают минусы вроде размера => проблем с обновлением.

Что Вы иметь в виду? :)

думаю, он о статической линковке

Ну что проще - это точно. Но правильней ли? Ведь dll-ки в папке будут грузиться только для данного приложения. Др словами если есть N папок с одинаковыми dll (и приложения из них запущены)- в памяти будет N копий всех dll

Таки да, я о статической линковке.
Ведь вроде без зависимостей - это как раз статика. а динамическая линковка и есть с зависимостями.

to Igors
Вот когда вы сделаете dll-ку в 500 мб, это возможно будет вызывать проблемы. А пока их размер < 50 мб это несущественно. К тому же динамика даёт возможность иметь на компьюторе много версий одних библиотек и без путаницы.

Хотя конечно можно было бы сделать менеджера dll-лок, который бы регистрировал версию/размер и прочие признаки и по которым отдавал бы каждому приложению запрашиваемые dll-ки, но это требует разработки стандарта :)

Такова плата за простоту. Вот представьте что будет если в систему установить несколько программ, каждая из которых использует Qt-либы, причем разные (64/32/мингв/mcvcXXXX)

В случае N папок с одинаковыми dll... Был у нас такой программный комплекс - порядка 60-и екзешников и 200-т библиотек; и был к этому добру инсталлер, которым никто не пользовался, а тупо все копировали в одну папку.
К чему это я... а к тому, что если библиотеки сторонние, то лучше подстраховаться и подсунуть в папку запуска именно те с которыми производилась сборка. Если же библиотеки свои, то за каким х-м дублировать их в N папок?

Смотря какой софт пишется.
Если это единственный процесс, например, десктоп приложение, мобильный сервис и т.п. - статическая линковка может быть и оправдана.
Если у вас распределенная система с десятками (сотнями/тысячами) сложных процессов, то ИМХО однозначно динамическая линковка.

На счет наличия инсталлятора - то лучше иго иметь, чем не иметь. Можно конечно и целую папку/мамку копировать, но бывает нужно какой-нибудь скрипт запустить, чтобы рабочее окружение для приложения сформировать, чтобы нужные версии библиотек использовались или еще чего. Кроме того, инсталлятор позволяет следить за обновлением версий, конвертацией форматов данных и т.п.

статику неудобно обновлять - большой размер

я считаю статическая сборка предпочтительнее динамической в большинстве случаев. Инсталлятор в разы меньше весит. Обновлять - так все равно Qt раз в 3 месяца обновляется, дллки новые. Если же есть несколько исполняемых файлов у продукта, то тогда, конечно, размер статики меньше динамики не будет. Но за статическую сборку надо платить (в прямом смысле).

Так часто получается если приложение что-то считает в течение длительного/ощутимого времени. Юзер может открыть вторую копию приложения и запустить др расчеты, это нормально

А как тогда с плагинами приложения (если сборка статическая)? И что тогда делает инсталл?

Инсталл подчищает хвосты. А то сейчас пошли приложения, напакостят в системе/реестре/папках пользователя, удалятся и оставляют свой мусор :)

Что мешает юзеру запустить вторую копию приложения из той же папки?

А как тогда с плагинами приложения (если сборка статическая)? И что тогда делает инсталл?
[/quote]

С плагинами проблем нету. А инсталлер копирует все файлы проекта (все равно их больше, чем один получается, как правило), делает всякие настройки и записывает для анинсталлятора что потом удалять. Но даже если и один файл, то все равно для рядового юзера инсталлер нужен.

Так может лучше не мусорить (не лить свое файло в систему) чтобы потом не подчищать?  :)

Тогда надо куда-то селить файлы данных/кеши/результаты иначе они перехлестнутся в папке приложения. И вообще: если мы разрешаем юзеру копировать - почему он не может сделать это N раз?

А как это? Допустим плагин хочет показать свое окно, откуда он возьмет для этого Qt?
Хммм....

И вообще... что мешает юзеру один раз отинсталлиться, а N-1 раз скопировать...
И вообще... что мешает юзеру отинсталлиться N раз в N разных папок
И вообще... ... ...
   все что угодно можно довести до маразма

А место для данных/кешей/результата можно и/или должно параметризировать аргументами с которыми запускается программа или простеньким инишником

Или путь к кешу должен быть стандартизированным и обязательно удаляемым при деинсталляции.

Я имел в виду статически cлинкованные плагины (напр. типа imageformats)

Плагин статически слинкованный - это уже не плагин :D
Плагин это - plug in. Подключаемый/отключаемый модуль. А в статике они все завязаны :D

Потому для каждого плагина(неслинкованного) придётся кутешные библиотеки тащить. Мало того, это врядли поможет. Хотя интересно проверить - что будет при загрузке Qt плагина в статическое приложение. По логике выходит что будет бардак :D

Плагины как раз обычно линкуются статически (насколько это возможно), иначе придется вместе с плагином еще кучу дллок таскать.

Не, вы имеете в виду, что сам плагин статически слинкован. Но при этом в приложение он подгружается динамически :)
А плагин, который статически слинкован к приложению - уже не плагин, а часть приложения.

Ну а как иначе он должен подгружаться? В этом основная суть плагина, что он грузится динамически.
Иначе это просто библиотека.

Ну есть Qt-шные плагины типа qjpeg и т.п., которые нафиг надо динамически иметь.
Плагины для своего проекта, особенно от третьих лиц, это уже плагины действительно.

Кстати о плагинах: а вот как грузятся те же imageformats? Откуда плагин берет хотя бы Qt5Core.dll? Ведь в папке плагина его нет

Тут вот глянул пару ссылок
https://wiki.qt.io/Deploy_an_Application_on_Windows (https://wiki.qt.io/Deploy_an_Application_on_Windows)
http://doc.qt.io/qt-5/windows-deployment.html (http://doc.qt.io/qt-5/windows-deployment.html)

И вроде ни о каком инсталлере речь не идет, я так понял что рекомендуют именно "сделать папку которую юзер может копировать". Все-таки налицо некоторая неряшливость - пользователь никогда не должен трогать тот же Qt5Core.dll, а мы его выставляем на передний план (все кишки наружу)

Ладно, теперь вот что хотелось бы обсудить: ну а инсталлер, чем он лучше в плане тех же dll ?  Он пропишет чего-то  в PATH? Так это не очень надежно, как уже говорили, dll с одним именем может быть откомпилена разными компиляторами. Выходит инствлл - не инсталл, ото "клади рядом с exe-шником если хочешь чтоб работало". Или как?

Плагин берёт дллки с рабочего каталога приложения. Т.е. загружает его приложение, поиск идёт - папка приложения и потом уже дальше по инстанции.

Инсталлер установит куда-то что-то, запишет куда и что установлено и при деинсталляции удаляет.  Никакой нагрузки на пользователя.А в случае с dll нагрузка на удаление ложится на пользователя. И не факт что пользователь узнает, что вы создали каталог "ам ам ам" в папке пользователя и туда положили файлы настроек. И будут они лежать вечным грузом, аминь.

1. Plugins can be linked statically into your application. If you build the static version of Qt, this is the only option for including Qt's predefined plugins. Using static plugins makes the deployment less error-prone, but has the disadvantage that no functionality from plugins can be added without a complete rebuild and redistribution of the application.

2. Смысл инсталлера/анинсталлера в удобстве для конечного юзверя. Куда при этом устанавливаются файлы - вопрос параллельный. (Конечно из-за всех этих dll-хеллов, sxs-херни (side-by-side что-то там), манифестов с версиями внутри просто не хочется возиться с этим говном, проще все носить с собой. Времена, когда десятки/сотни мегабайт были значительной частью винчестера, уже прошли.) Продвинутый юзер может предпочесть и, например, portable app вместо инсталлируемой - можно предлагать такую опцию.

3. При динамической сборке можно легко подменить Qt-шные дллки на модифицированные свои, где логируется вся активность внутри QObject'-наследованных классов, и т.о. легко* реверс-инжинирится логика программы

Обычно инсталлятор производит больше действий, чем тупое удаление/копирование файлов. Он может настраивать конфигурационные файлы (например, по заданному шаблону), используя информацию с локального ПК; проверять версию предыдущей установки; проверять наличие зависимых компонентов; предоставлять выбор пользователю состава устанавливаемого ПО; проверять совместимость железа, ОС и др. факторов; запрашивать лицензию и много всего другого.

Если ничего из этого не требуется для работы ПО, пусть распространяется простым копированием - будет переносимым приложением (https://ru.wikipedia.org/wiki/Переносимое_приложение (https://ru.wikipedia.org/wiki/Переносимое_приложение)).

То еще очень мягко сказано

На диске да, но разбазаривание RAM грамотным никак не назовешь. Причем никаких правильных/корректных решений Вындоуз не предлагает. Ну возьму я на себя еще заботы с инсталлером - и что, куда я дену Qt dll-ки? Вот если есть солидный/штатный установщик (напр redistribute MSVC) - тогда да. По существу - имя dll уникально

Ну копирование тоже сложностью не страдает. Думается инсталлер часто - просто ритуал.

Список солидный, но многое из него можно делать и на запуске приложения

Это правило "дружелюбной" программы.
Для Windows установка при помощи установщика, с записью в список устанавливаемых программ, с деинсталлятором - признак хорошего тона.
Это позволяет пользователю сразу видеть в одном месте список установленных программ и работать с ним, а не лазить по папкам и надеяться на собственную память.

По сути, это не обязательно, но удобно для пользователя. Переносимые программы игнорируют это правило, но это нормально. Переносимых программ не так много, их все запомнить можно.

Для *nux установка ПО с помощью пакета со всеми зависимостями - признак хорошего тона too  ;D.

Вот вот, какая б ни была ОС, нужно все яйца класть в корзину.

Если нетрудно, расскажите подробнее - на примере установки приложения использующего Qt.

На OSX немногие приложения инсталлятся (хотя делать это как в линукс не запрещено). О каких-то де-инсталляторах никогда не слыхал. Напр Xcode (аналог MSVC) инсталлится. Чтобы снести (редко) нахожу в гугле команду и copy/paste в консоль. Что она делает - хз, но это можно пережить т.к. инсталлируемых приложений мало. 

В оригинале
:)

Если б я хотел привести оригинал, я б копирайт поставил.  Более того там речь о реальном мире шла, а у нас разговоры про программы.

В репозиториях каждой из OC имеются пакеты qt разных версий. Не факт, что версия из репозитория нас устроит, так как обычно она не является актуальной. В этом случае мы можем сами сформировать пакет для сборки и установки Qt со всеми необходимыми зависимостями. Пакеты могут быть как бинарными, так и состоять из исходников, с любом случае процесс установки (сборки и развертывания) происходит автоматически (qmake, make, make install).

В своих пакетах мы указываем зависимости от пакетов Qt (если есть в офиц. репозитории) или поставляем пакеты для Qt, сформированные нами (тогда указываем зависимости от них).

Как сформировать, например, rpm пакет описано здесь (оригинал http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/index.html (http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/index.html), перевод http://www.opennet.ru/docs/RUS/rpm_guide/ (http://www.opennet.ru/docs/RUS/rpm_guide/)).

Мда, таким хорошо по темечку бить  :)