On Friday 09 August 2013 21:34:08 Thomas Lübking wrote: > On Donnerstag, 8. August 2013 10:04:10 CEST, Pali Rohár wrote: > > On Wednesday 07 August 2013 15:07:39 Jan Kundrát wrote: > >> On Wednesday, 17 July 2013 21:42:04 CEST, Pali Rohár wrote: > >>> My current code have common "interface" classes for > >>> password and addressbook plugins. Because trojita working > >>> only with pointers of these common objects, code of > >>> interface classes must be statically linked into trojita > >>> executable binary. > >> > >> I don't follow here. > >> > >>> But plugin implementation inherit from common interface > >>> class, so constructor (and other qobject moc methods) must > >>> be accessible from plugin shared library. > >>> > >>> So there are two possible methods: > >>> 1. static link code of interface classes to both trojita > >>> executable and to plugin shared library > >>> 2. link interface code only to trojita executable and > >>> export symbols to be accessible by loaded libraries > >> > >> Would the following work? > >> > >> 3) Move the common code into a shared library and have both > >> trojita-the-library and any plugin link with said shared > >> library. > >> > >> Jan > > > > This means that all code which is needed by plugins must be > > moved into shared library. So then trojita will have one > > executable binary and one shared library. Both binaries > > will be needed to run trojita and trojita version without > > plugins... Do you think that this is really acceptable > > solution? > > Sorry for the late hook in. > > Eg. kwin links libkdecoration.so and so do the deco plugins. > > > Static linkage of interfaces into plugins and core will not > allow you to maintain plugin versions and probably even break > when changing enums. > > Having plugins link trojita and exported symbols directly will > get you into ABI trouble, as you cannot touch the ABI of the > core w/o breaking plugin ABI - no problem as long as all > plugins are developed within trojita, but distros will start > to hate you, when their 3rd party plugins break on random > trojita updates (and you will hate yourself when you've to > maintain ABI in the core) > > If supporting trojita w/o plugins is a target, trojita could > still attempt to dlopen libtrojitaplugins. > > Keeping "stuff in libtrojitaplugins" tight might require a > bridge (ie. an abstract of the required functions in > libtrojitaplugins, implemented in trojita and passed on > plugin construction) > > Cheers, > Thomas
Ok, I can try to create shared library for plugins and will try to change trojita code to load that library at runtime. But this will drop support for static linked plugins directly into trojita binary. -- Pali Rohár [email protected]
signature.asc
Description: This is a digitally signed message part.
