On Saturday 07 September 2013 03:51:16 Thomas Lübking wrote: > On Samstag, 7. September 2013 02:18:48 CEST, Pali Rohár wrote: > > On Friday 06 September 2013 20:23:19 Jan Kundrát wrote: > >> ...which is why I like Thomas' suggestion to use actual > >> instantiation of the basic plugins like > >> passwords-in-qsettings, i.e. the call to a "impl = new > >> FooPlugin(...)". FooPlugin's constructor can come from a > >> shared library, and dynamic linker will make sure that > >> Trojita won't run unless that library is found -- that's > >> what I meant here. > > > > But this disable support for run-time plugins. > > Why? This is only about the "stock" plugins you want to > compile in. You can try to load a dynamic plugin for the name > first (overriding compiled in) or after (extending only) and > if you want to be able to compile trojita w/o any compiled in > plugins, you just put the direct object instatiation into an > #ifdef and remove the source files in CMake (or rather not > add them) >
So why adding new code "impl = new" for each plugin, if Qt support Q_IMPORT_PLUGIN which adding plugin into QPluginLoader? This means that some plugins can be initialized only via "new" and some plugins only via QPluginLoader... This will increase plugin manager code, complicate it and make hard to understand. > > I do not agree, for me it sounds stupid if I have to > > recompile full application only because I want to move its > > binary (or other libary) from directory A to B. > > To me as well - sounds as if the path resolution was in a > global header included everywhere. Usually you're recompile > one object and then relink. > > Leaving aside that for LD resolution that's not required > anyway, since LD_LIBRARY_PATH allows you to do anything > stupid. > > So this is only a concern for dlopened (plugin) libraries. > > > But trojita itself is not application which needs > > administrator rights for running. So why depends on it for > > installation procedure? > > Because package managers won't like if you cross them? > And why would you try installing it differently in the first > place? Or move around files? > Because I couldnt have admin rights? Or because I moving my local executable binaries to another place? Really, I have more programs in ~/bin/ and every program working fine if is started from any location. And I do not see reason why trojita should have problems with it. > > Also why to limit loading plugins from runtime directory > > only on some systems? This sounds like bad design. > > Yes, but we've no impact on the poor Software distribution on > windows. > > > I think that plugins should be located: > > 1. in current application directory (or subdirectory) > > 2. in well-known system directory (or specific subdirectory) > > if for system there is well-known location (e.g > > LIBDIR/trojita/ or other location defined by system package > > manager) > > I really don't your point here. > Either you get it via package management - then you don't want > to move it around, since you'd miss updates, the package > manager might complain about missing files etc. Or you > compiled it yourself - then you can choose the plugindir > anyway. > At compile time. I'm not able to copy binary to another computer. I need to compile it also on that computer with different (system) plugin path. Really why is problem first trying to load plugins from executable directory? > The usecase is "Windows" because users don't know what a > compiler is and usually choose the installation path on > setup.exe - And though you'll usually need Admin rights to > install on windows as well I don't see why anyone would want > to import this questionable model. > And portable versions? -- Pali Rohár [email protected]
signature.asc
Description: This is a digitally signed message part.
