On Friday 06 September 2013 20:23:19 Jan Kundrát wrote: > On Friday, 6 September 2013 12:56:56 CEST, Pali Rohár wrote: > > You forgot to include [1] link. > > Oops, http://labplot.sourceforge.net/developer/plugins/. > > >> -> Is there really a problem with adding a *static plugin* > >> into a *shared library*? > > > > I think yes, because that qt plugin instance function comes > > from static library linked into dynamic. And for this is > > whole-archive flag needed. > > By "static plugin", I meant using the Q_IMPORT_PLUGIN within a > shared library. I understand that the implementation of this > plugin cannot be done via a static library because one cannot > build a shared library from a few static libraries in cmake > without explicit linker massaging. > > > This is easy and simple, just one cmake option switch and if > > statement. And it can be usefull if trojita is compiled with > > 2 defined static plugins and other dynamic plugins are not > > needed. > > Yes, it's doable. It's also a hack, it is contrary to how it's > done by other projects, very non-Qtish, and also discouraged > by Thiago, Thomas and me. > > >> I'd prefer to rely on the dynamic linker to check for > >> "obviously bad" installation -- hence my suggestion to move > >> the basic static plugins into a required shared library. > > > > Searching for plugins is not done by dynamic linker, but by > > trojita code itself (in our case by QPluginLoader). > > ...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. Every plugin must be referenced in source code - which means no differences between this solution and static linking plugins into executable. > > No, this is for users who do not want precompiled OBS > > version with more plugins... > > Ah, so this is about "how to package Trojita". In order to > target the RPM and DEB-based distributions, I'd like to ship > one package "trojita" which contains just the application > (with some shared libraries if it needs them, and *including* > the basic plugins like passwords-in-qsettings, preferably not > as dlopen()-ed plugins). Next to that "trojita" package, > let's create a ton of packages for the optional plugins -- > basically one package per one plugin. Yes, this means that > the standalone "trojita" package will ship with a "useless" > shared library libtrojitapluginsprivate. That's acceptable to > me. > > (On Gentoo, there should be a single package with USE flags > controling what to build, but that's not relevant for > mainstream desktop Linux.) > > > Yes, moving build directory is something which we do not > > care about. But moving binary without build directory > > should work and not break full application. > > The only two configuration I want to help Unix users with are: > > 1) proper installation via `make install` or package manager > 2) runnig straight from the build directory > > > This is also common on windows > > platform, where user choose where he will put executable > > binary *not* at compile time. > > I'm fine with a Windows-specific feature saying "look for > runtime-loaded objects next to the directory where the binary > resides" (which is, to be absolutely clear here, to be > determined at runtime). I don't have any opinion (yet) on > whether this shall be enabled on Unix as well; I suspect I'll > be inclined to "no". > > OK for you? > 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. You are right that proper installation should be done by make install to /usr/local or /opt or installing application by package manager, but both operations needs administrator rights. But trojita itself is not application which needs administrator rights for running. So why depends on it for installation procedure? Also why to limit loading plugins from runtime directory only on some systems? This sounds like bad design. 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) My current code is doing that. > >> 1) Hardcode --whole-archive and produce the following targets: > [...] > > > This means to drop all non gcc compilers/linkers. And you > > already wrote that these hacks are not acceptable. > > Perosnally, I'd call this a "cmake limitation", but I agree > that it is suboptimal. > > >> 2) Produce a ton of shared libraries > > [...] > > > See my objections about tons of private libraries. > > For me, a good argument against this is that these libraries > are actually not self-contained, but come with > interdependencies. I also do not want to go this direction. > > > Yes, option 3) is for me the best. It only waste disk space > > (kontact and trojita have duplicated code), but only one > > version is used at one time. And it does not need to relink > > every binary after single change (e.g version string) > > Looks like we're in violent agreement here, then :). I also > like #3. > Ok, I updated review request. > How would you like to ship the basic plugins > (passwords-in-qsettings and probably also abook-addressbook) > -- as a dlopen()ed plugin, or via Q_IMPORT_PLUGIN? This is good question. Current cmake code can build any plugin as shared library or static Q_IMPORT_PLUGIN (cmake option). So we can discuss about default behaviour. I think that passwords in qsettings plugin can be compiled into trojita executable by default and shared version of plugin could be disabled. -- Pali Rohár pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
