Насколько нужна сборка приложения "без зависимостей"

[vipet]

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

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

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

[Igors]

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

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

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

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

[Igors]

С плагинами проблем нету.

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

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

Хммм....

[kai666_73]

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

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

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

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

[Bepec]

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

[vipet]

С плагинами проблем нету.

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

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

[Bepec]

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

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

[Racheengel]

Плагин статически слинкованный - это уже не плагин

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

[Bepec]

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

[Racheengel]

Не, вы имеете в виду, что сам плагин статически слинкован. Но при этом в приложение он подгружается динамически

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

[vipet]

Не, вы имеете в виду, что сам плагин статически слинкован. Но при этом в приложение он подгружается динамически

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

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

[Igors]

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

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

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

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

[Bepec]

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

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

[vipet]

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

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

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

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

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'-наследованных классов, и т.о. легко* реверс-инжинирится логика программы

[ssoft]

Ладно, теперь вот что хотелось бы обсудить: ну а инсталлер, чем он лучше в плане тех же dll ?

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

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