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.
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?
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.
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?
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
