How to link against QSvgIconEnginePlugin?
-
Starting point
I'm developing a Qt based library. It uses CMake as build system. Both, static and shared/dynamic builds are supported. The library compiles currently against both, Qt5 and Qt6, but Qt5 support will be dropped in the future. It builds on FreeBSD, Linux, and Windows. Further platforms could be added in the future.
When I need to add a dependency like Qt::Widgets, I do something like that in modern CMake:
find_package( Qt${QT_MAJOR_VERSION} COMPONENTS Core Gui Widgets REQUIRED) target_link_libraries(PUBLIC Qt::Core Qt::Gui Qt::Widgets)That communicates automatically the dependencies. When someone builds against my shared/dynamic library and Qt::Widgets is missing at build or at run time, this results in an error. Also, when someone builds against my static library, a missing Qt::Widgets will trigger an error. That is a clear communication.
Problem
Now I want to add a new dependency on QSvgIconEnginePlugin, because I want to use built-in (via Qt resource compiler) SVG icons. I suppose that a missing QSvgIconEnginePlugin will not trigger any build error, and I will get silently an empty QIcon when I try to load SVG icons while QSvgIconEnginePlugin is missing. So I thought it might be good to link explicitly against QSvgIconEnginePlugin to make sure it is available. However, I did not find a target to link against. It seems that Qt::QSvgIconEnginePlugin isn’t a valid target name. I could hard-code it and link against plugins/iconengines/libqsvgicon.so on my Linux distribution, but this won’t work cross-platform. Also, I found qt_import_plugins but that seems to be only for static Qt builds. Its documentation speaks about default plugin lists. Is there any guarantee that Qt::QSvgIconEnginePlugin is available always on all platforms?
-
Starting point
I'm developing a Qt based library. It uses CMake as build system. Both, static and shared/dynamic builds are supported. The library compiles currently against both, Qt5 and Qt6, but Qt5 support will be dropped in the future. It builds on FreeBSD, Linux, and Windows. Further platforms could be added in the future.
When I need to add a dependency like Qt::Widgets, I do something like that in modern CMake:
find_package( Qt${QT_MAJOR_VERSION} COMPONENTS Core Gui Widgets REQUIRED) target_link_libraries(PUBLIC Qt::Core Qt::Gui Qt::Widgets)That communicates automatically the dependencies. When someone builds against my shared/dynamic library and Qt::Widgets is missing at build or at run time, this results in an error. Also, when someone builds against my static library, a missing Qt::Widgets will trigger an error. That is a clear communication.
Problem
Now I want to add a new dependency on QSvgIconEnginePlugin, because I want to use built-in (via Qt resource compiler) SVG icons. I suppose that a missing QSvgIconEnginePlugin will not trigger any build error, and I will get silently an empty QIcon when I try to load SVG icons while QSvgIconEnginePlugin is missing. So I thought it might be good to link explicitly against QSvgIconEnginePlugin to make sure it is available. However, I did not find a target to link against. It seems that Qt::QSvgIconEnginePlugin isn’t a valid target name. I could hard-code it and link against plugins/iconengines/libqsvgicon.so on my Linux distribution, but this won’t work cross-platform. Also, I found qt_import_plugins but that seems to be only for static Qt builds. Its documentation speaks about default plugin lists. Is there any guarantee that Qt::QSvgIconEnginePlugin is available always on all platforms?
@sommerluk even when you link the plugin to your app, you app may not work either. I guess the reason is that the qt code still looks for the plugin to load and it is not available unless . you change the qt source code to drop this plugin loading part. Maybe the better way to handle it is to wrap the plugin with your app like a so file and set the path properly as plugin.
-
Hi,
That plugin is available though the svg module so you have to deploy it along your application.
-
Okay. If I understand correctly:
That plugin is available though the svg module
So it is useful to link against the Qt::Svg module.
- On Linux and FreeBSD, this will force the distribution’s package manager to add Qt::Svg as dependency, and the Qt::Svg package which will very likely at the same time provide QSvgIconEngine.
- On Windows, there is no package management. However, it will do no harm to link against Qt::Svg, as the Qt::Svg module has to be deployed anyway to provide QSvgIconEngine.
so you have to deploy it along your application.
wrap the plugin with your app like a so file and set the path properly as plugin
I do not provide binaries. Currently, I document the build-time dependencies. So here the point would be to document QSvgIconEngine as an additional run-time dependency for deployment.
