On Sunday 08 September 2013 19:47:12 Thomas Lübking wrote: > On Sonntag, 8. September 2013 14:19:02 CEST, Pali Rohár wrote: > > Ok, so I see that everybody is against loading plugins from > > application directory. > > > > What about this solution? > > > > Load plugins from system path specified at compile time and > > also from some application subdirectory (plugins). And > > third posibility so specify custom path via env variable, > > command line option or config option. > > If you install plugins into the Qt plugin path, there's > $QT_PLUGIN_PATH anyway. Loading from "./plugins/" is no > different than loading from "." - basically just the plugin > name changed from plugin_foo to plugin/foo and this is also > superseded by an env strategy (since you can put "." into the > inv list if you really want to) >
QPluginLoader (and my current code too) not using $QT_PLUGIN_PATH variable, so it will not work. And my question is what do you think about searching for plugins in "./plugins/" directory (instead ".") and in $SOME_ENV_PATH directory? It is acceptable? > > What I do not want is hardcoding build directory into > > trojita executable when build service compiling package > > (rpm, deb, ...). > > I do not understand the usecase for this, but it's Jans > decision anyway. > > > loading plugins from rpaths? It is even possible to read > > rpath in application? > > Yes, unless you mean "in a portable way that does not include > inspecting the ELF" > http://stackoverflow.com/questions/2836330/is-there-a-way-to-> > inspect-the-current-rpath-on-linux > > PE/COFF will require different treatment for sure. > No, no, this is really horrible hack and from what I found windows does not support equivalent to rpath. So drop this. -- Pali Rohár [email protected]
signature.asc
Description: This is a digitally signed message part.
