On 04/11/2012 06:00 PM, Toshio Kuratomi wrote:
On Wed, Apr 11, 2012 at 05:00:36PM +0200, Brendan Jones wrote:
Hi all
I have a library (suil [1]) currently under review [2] which enables
audio software such as qtractor/ardour etc to instantiate LV2 audio
plugins. Whilst not part of the LV2 specification, it is being
maintained by the authors of LV2 and will obsolete slv2 which is what
hosts currently use.
An instantiated plugin may use a different UI toolkit than the host
and one of purposes of the suil library is to free the host
application from unnecessary explicit runtime toolkit dependencies
(Qt/Gtk only at this stage).
I'm going to paraphrase what you said here and what's in the review request
to be sure I understand :-)
Sorry, its hard too explain concisely without presenting a tome of
information! Thanks for paraphrasing, few comments below which may clear
things up (or not :|)
There is a library named suil whose purpose is to allow an application to
require one UI toolkit and that application's plugins to require a different
UI toolkit.
The suil library itself has compiled plugins that enable different types of
embedding (qt4 in gtk2 and gtk2 in qt4 at the moment). These suil plugins
need to require two toolkits apiece: the toolkit that is being embedded and
the toolkit that is being embedded into.
suil is somewhat parallel to the spec - the host could instantiate the
plugin on its own (using lv2core) if it wanted to. I guess the best way
is to consider suil a helper library using lv2core which saves the host
from doing the heavy lifting.
As it stands RPM automatic requires will pull in requires for both
toolkits, so that any Qt host using suil will pull in Gtk and vice
versa. Whilst on most systems these will be present anyway it may not
always be the case nor desirable (and it kind of defeats what
upstream have set out to achieve).
I can filter out the toolkit requires in suil which will solve the
problem, but it leaves the maintainer (me for now) in a position of
manually tracking changes in Qt/Gtk that may require a rebuild of
suil.
Alternatively I could filter the requires on any hosts that use suil,
(only one at this stage but inevitably more), but that again this is
cumbersome as more and more hosts come onbooard.
The safest course is to leave the automatic requires alone, pull in
both toolkits for every host and deal with it differently when/if
asked but it doesn't sit *right* with me.
Any comments on the best way to handle this?
Assuming that I understand what suil does, I think this is what things
should look like:
* Main suil package which contains libsuil. This does not depend on any
toolkits.
* Subpackages per embedder that are named like this: suil-gtk2-in-qt4
and Require the two toolkits that the plugin needs (in this case, gtk2 and
qt4).
suil will read the metadata of the plugin bundle, find its location,
determine what toolkit it requires and employ one of suil-gtk2-in-qt4 or
suil-qt4-in-gtk2 libraries to work out what it needs to do
* An application that depends on suil will require the main suil package and
separately, the toolkit library that it depends on (automatically
extracted by rpm if the application was linked correctly).
Yes, ideally a host application will require suil, and suil only.
* A plugin for the application will:
** Always depend on the main suil package.
Never, no LV2 plugin will ever know about suil.
** Also have a dependency on the toolkit library that it depends on
(automatically extracted by rpm if the application was linked correctly).
Correct, so we are not touching any of the automatic dependencies of the
plugin
** Additionally, the plugin package needs to know what toolkit the
application is using. If it is different than the toolkit that the
plugin is using, the plugin's rpm package will have a manually added
dependency on the proper suil subpackage for embedding.
Again, a plugin has no foreknowledge of its host nor any intermediate
library which may be used to instantiate it.
Whilst filtering the requires solves one problem, it creates another and
thats tracking abi changes etc against suil. Positive in one sense as
only suil will ever need rebuilding when this occurs?
thanks for the patience
Brendan
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
