AlienCowEatCake / ImageViewer

Simple, cross-platform image viewer
GNU General Public License v3.0
25 stars 4 forks source link

ThirdParty #17

Open aaly11 opened 2 weeks ago

aaly11 commented 2 weeks ago

Привет. Собрал пакеты rpm и deb для openSUSE Tumbleweed, и Ubuntu 24.04. Пакеты .src.rpm и .orig.tar.gz просто чрезвычайного размера. Большинство используемых программой библиотек уже заботливо собраны в дистрибутивах. Имеется ли смысл в огромном thirdparty? Если ставится задача на поддержку неограниченного количества читаемых форматов файлов, то может решать её с помощью плагинов - не создавать неповоротливого монстра, а лишь навешивать "доспехи"?

AlienCowEatCake commented 2 weeks ago

Привет!

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

Каким образом, по-вашему, плагины решат проблему? С плагинами будет все ровно то же самое, исходники их займут ровно столько же места (на самом деле даже чуть больше, но можно этим пренебречь). Разбивать на несколько независимых репозиториев? Это значительно усложнит разработку, потеряется возможность собирать статические сборки, плюс очень сильно утяжелятся итоговые бинари с несистемными библиотеками.

Я могу предложить такие варианты:

  1. Делать в релизах дополнительный тарболл без thirdparty библиотек. Но вы, если я правильно понял, используете git, а не тарболлы, поэтому не уверен, что вам это подойдет
  2. Я так понимаю, вы пытались сделать exclude на неиспользуемые части, но т.к. там много мест, где указаны версии, которые меняются, то у вас не вышло. Что если сделать дополнительный уровень каталогов, то есть вместо src/ThirdParty/aom/libaom-3.9.0 будет src/ThirdParty/aom/ext/libaom-3.9.0, например? Тогда вы сможете прописать <param name="exclude">src/ThirdParty/aom/ext/*</param>. Или даже может <param name="exclude">src/ThirdParty/**/ext/*</param>, если там такой синтаксис поддерживается
AlienCowEatCake commented 2 weeks ago

Насчет пакетов. Рекомендую взглянуть в src/Features.pri#L836-L875, у вас получаются немного избыточные сборочные зависимости и взаимоисключающие опции сборки:

AlienCowEatCake commented 2 weeks ago

Я так понимаю, вы пытались сделать exclude на неиспользуемые части, но т.к. там много мест, где указаны версии, которые меняются, то у вас не вышло. Что если сделать дополнительный уровень каталогов, то есть вместо src/ThirdParty/aom/libaom-3.9.0 будет src/ThirdParty/aom/ext/libaom-3.9.0, например? Тогда вы сможете прописать <param name="exclude">src/ThirdParty/aom/ext/*</param>. Или даже может <param name="exclude">src/ThirdParty/**/ext/*</param>, если там такой синтаксис поддерживается

Я тут еще подумал, возможно даже не нужен дополнительный уровень каталогов. Попробуйте вот такой паттерн: <param name="exclude">src/ThirdParty/**/**/*</param>. Если такой синтаксис поддерживается, это должно решить вашу проблему. А за одно можно и <param name="exclude">.appveyor.yml</param> вместе с <param name="exclude">.gitignore</param> добавить, для большего облегчения

aaly11 commented 2 weeks ago

Для включения программы в дистрибутив настоятельно рекомендуют, для сборки, использовать системные библиотеки. Такая политика безопасности в любом без исключения дистрибутиве. Наличие ThirdParty вызывает вопрос:"Откуда что берётся?" К примеру, сборка для openSUSE Leap 15.6 заканчивается неудачей. Программа сборки пытается найти исходные файлы необходимых библиотек, которые были исключены из архива с исходным кодом (imageviewer-1.6.1+git34.7877f841.tar.xz), а эти же системные библиотеки не установлены. И нет внятного правила сборки (disable_openexr).

Я могу предложить такие варианты:

  1. Делать в релизах дополнительный тарболл без thirdparty библиотек.

Такой вариант очень желателен.

AlienCowEatCake commented 2 weeks ago

Я могу предложить такие варианты:

  1. Делать в релизах дополнительный тарболл без thirdparty библиотек.

Такой вариант очень желателен.

Вы планируете собирать не из git?

Для включения программы в дистрибутив настоятельно рекомендуют, для сборки, использовать системные библиотеки. Такая политика безопасности в любом без исключения дистрибутиве.

Поэтому и есть вариант собирать с системными зависимостями

И нет внятного правила сборки (disable_openexr).

Что значит нет внятного правила? disable_openexr/system_openexr и есть документированные конфигурационные опции для того, чтобы задать нужный вариант сборки зависимости OpenEXR. По умолчанию используется встроенная версия. Если вы ее исключаете из исходников, то вам нужно явно задать нужную опцию

К примеру, сборка для openSUSE Leap 15.6 заканчивается неудачей. Программа сборки пытается найти исходные файлы необходимых библиотек, которые были исключены из архива с исходным кодом (imageviewer-1.6.1+git34.7877f841.tar.xz), а эти же системные библиотеки не установлены.

Взгляните в логи сборки, а именно в то, что приходит на самом деле в качестве опций конфигурации:

[   54s] + /usr/lib64/qt6/bin/qmake 'QMAKE_CXXFLAGS= -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -g' 'QMAKE_CFLAGS= -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -g' 'QMAKE_LFLAGS= -Wl,--as-needed -Wl,--no-undefined' 'CONFIG+=release enable_pkgconfig' 'CONFIG+=disable_aom disable_brotli system_exiv2 system_flif' 'CONFIG+=disable_freetype system_giflib disable_highway system_jbigkit' 'CONFIG+=system_jxrlib disable_kimageformats system_lerc' 'CONFIG+=system_libavif disable_libbpg disable_libde265 system_libexif' 'CONFIG+=disable_libexpat system_libheif system_libjasper' 'CONFIG+=system_libjpeg system_libjxl system_liblcms2 system_libmng' 'CONFIG+=system_libpng system_libraw system_librsvg system_libtiff' 'CONFIG+=system_libwebp system_libwmf system_openjpeg' 'CONFIG+=disable_qtimageformats disable_stb disable_xzutils system_zlib' 'CONFIG+=disable_zstd disable_ghc_filesystem' 'CONFIG+=disable_graphicsmagick disable_graphicsmagickwand' 'CONFIG+=disable_magickcore disable_magickwand' 'CONFIG+=disable_nanosvg disable_qmlwebengine disable_qtextended' 'CONFIG+=disable_qtwebengine system_resvg' INCLUDEPATH+=/usr/include/jxrlib INCLUDEPATH+=/usr/include/openjpeg-2.5 INCLUDEPATH+=/usr/include/freetype2 INCLUDEPATH+=/usr/include/Imath

Здесь нет ни disable_openexr, ни system_openexr, поэтому пытается использоваться встроенная версия, которой нет

aaly11 commented 2 weeks ago

По моему скромному мнению system_ должно быть по-умолчанию. Я должен быть уверен, что будут использованы системные библиотеки, какие бы ошибки я не совершал, а вы всё принимаете на свой счёт. Когда _systemkimageformats и _systemqtimageformats не существует, и чтобы использовать системные библиотеки необходимо выставить disable_ - это слишком замысловато.

AlienCowEatCake commented 2 weeks ago

По моему скромному мнению system_ должно быть по-умолчанию.

Повторюсь, мир не ограничивается дистрибутивами с библиотеками. Библиотеки есть в дистрибутивах GNU/Linux (не все и только в достаточно свежих, но допустим), *BSD, Haiku, MSYS2 (условно, т.к. часть из них не перемещаемые, но допустим). Если возьмем macOS - там уже все сильно хуже. Да, есть homebrew и MacPorts, только вот у них очень высокий deployment target, плюс как минимум в homebrew библиотеки собраны не универсальные и под слишком современные процессоры. Ну и да, часть все так же не перемещаемые. То есть библиотеки нужно собирать под проект все без исключения, некоторые еще и патчить. Под Windows нет даже этого. Если вспомним, что программа работает хоть на Windows 95, если взять достаточно старую версию Qt, подходящих готовых библиотек в 2024 году, очевидно, не будет. Поэтому system_* по умолчанию быть не может, это будет очень узко применимое решение

Я должен быть уверен, что будут использованы системные библиотеки, какие бы ошибки я не совершал

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

Когда system_kimageformats и systemqtimageformats не существует, и чтобы использовать системные библиотеки необходимо выставить disable - это слишком замысловато.

Выставлять disable* надо чтобы отключить, тут нет никакой двусмысленности. У kimageformats и qtimageformats нет system*, потому что с ними нельзя собраться в системном варианте, т.к. это изначально плагины для Qt. Вы можете поставить их отдельно как собственно плагины для Qt, и вся функциональность будет доступна программе через системный Qt. Только это уже не имеет никакого отношения к конфигурации программы, для нее эти компоненты будут отключены

aaly11 commented 2 weeks ago

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

Согласен с таким предложением на все сто.