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)
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?
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.
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.
Cheers,
Thomas
