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).
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?
thanks,
Brendan
[1] http://drobilla.net/software/suil/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=783825
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 :-)
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.
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). * 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). * A plugin for the application will: ** Always depend on the main suil package. ** Also have a dependency on the toolkit library that it depends on (automatically extracted by rpm if the application was linked correctly). ** 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.
So two hypothetical examples: Application foo which uses Qt4 and plugin bar that uses Qt4:
$ rpm -q --requires foo [..] libsuil.so.0 libQtCore.so.4 libQtGUI.so.4 [..]
$ rpm -q --requires bar [..] libsuil.so.0 libQtCore.so.4 libQtGUI.so.4 [..]
Application foo which uses Qt4 and plugin bar that uses gtk2:
$ rpm -q --requires foo [..] libsuil.so.0 libQtCore.so.4 libQtGUI.so.4 [..]
$ rpm -q --requires bar [..] libsuil.so.0 libgtk-x11-2.0.so.0 suil-gtk2-in-qt4 [..]
This dependency is explicitly specified in the bar spec file as: Requires: suil-gtk2-in-qt4
In the Review Request someone said they weren't sure why there needed to be subpackages for the embedders if all the embedders required the same libraries. The reason is that the matrix should also include the case where there's no cross-toolkit embedding occurring (example: application uses Qt4 and plugin also uses Qt4)
You could simplify somewhat by placing plugins that both require the same toolkits together. So hypothetically, if suil also supported wxwidgets you could have:
* suil ** main suil package with libsuil.so.0
* suil-gtk2-qt4 ** libsuil_qt4_in_gtk2.so ** libsuil_gtk2_in_qt4.so
* suil-gtk2-wx2 ** libsuil_gtk2_in_wx2.so ** libsuil_wx_in_gtk2.so
* suil-qt4-wx2 ** libsuil_qt4_in_wx2.so ** libsuil_wx_in_qt4.so
-Toshio
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
On Wed, Apr 11, 2012 at 06:45:15PM +0200, Brendan Jones wrote:
On 04/11/2012 06:00 PM, Toshio Kuratomi wrote:
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.
So.. what is a host and what is lv2core?
-Toshio
On 04/11/2012 08:27 PM, Toshio Kuratomi wrote:
On Wed, Apr 11, 2012 at 06:45:15PM +0200, Brendan Jones wrote:
On 04/11/2012 06:00 PM, Toshio Kuratomi wrote:
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.
So.. what is a host and what is lv2core?
A host is any application that instantiates an LV2 plugin - e.g. best known examples are apps like qtractor or ardour. Although there are others like lv2rack (which doesn't use suil). Eventually I think LV2 will be a drop in replacement for LADSPA plugins, but its not quite there yet.
On Wed, Apr 11, 2012 at 09:04:11PM +0200, Brendan Jones wrote:
On 04/11/2012 08:27 PM, Toshio Kuratomi wrote:
On Wed, Apr 11, 2012 at 06:45:15PM +0200, Brendan Jones wrote:
On 04/11/2012 06:00 PM, Toshio Kuratomi wrote:
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.
So.. what is a host and what is lv2core?
A host is any application that instantiates an LV2 plugin - e.g. best known examples are apps like qtractor or ardour. Although there are others like lv2rack (which doesn't use suil). Eventually I think LV2 will be a drop in replacement for LADSPA plugins, but its not quite there yet.
So -- I write a plugin and it can be hosted by any number of applications?
-Toshio
On 04/11/2012 09:26 PM, Brendan Jones wrote:
On 04/11/2012 09:16 PM, Toshio Kuratomi wrote:
So -- I write a plugin and it can be hosted by any number of applications?
Yes - the host application would either use lv2core or slv2 to do so.
Seeing as suil is deprecating slv2 - suil to do so
On Wed, Apr 11, 2012 at 09:26:30PM +0200, Brendan Jones wrote:
On 04/11/2012 09:16 PM, Toshio Kuratomi wrote:
So -- I write a plugin and it can be hosted by any number of applications?
Yes - the host application would either use lv2core or slv2 to do so.
Hmmm... okay
So how does this sound as a paraphrase... suil and lv2core are abstractions for running plugins. They are not abstractions for dependencies. What that means is that suil and lv2core allow a host application to run any plugin written for the lv2core framework But it can only do this if the proper deps are on the system. For instance:
Application foo written using Qt4 and application bar written using gtk2.
If any of qt4, gtk2, or the suil module that allows embedding gtk2 plugins in a qt4 application are missing, then the bar plugin cannot be loaded into the suil application.
With these constraints, I think you were (unfortunately :-( right about the choices. You need all of the siul modules installed since you don't know what combination of toolkits the particular application and plugin combos the user is running will need. Filtering the dependencies shouldn't be too bad for the end user. The plugin and the application will pull in the correct UI toolkit libraries for the suil module to work. But as the packager you then have to manually track things that ordinarily are just a repoquery away.
You might be able to use BuildRequires with a specific version to help alert you to problems and that's not a proactive approach.
-Toshio
On 04/11/2012 11:19 PM, Toshio Kuratomi wrote:
On Wed, Apr 11, 2012 at 09:26:30PM +0200, Brendan Jones wrote:
On 04/11/2012 09:16 PM, Toshio Kuratomi wrote:
So -- I write a plugin and it can be hosted by any number of applications?
Yes - the host application would either use lv2core or slv2 to do so.
Hmmm... okay
So how does this sound as a paraphrase... suil and lv2core are abstractions for running plugins. They are not abstractions for dependencies. What that means is that suil and lv2core allow a host application to run any plugin written for the lv2core framework But it can only do this if the proper deps are on the system. For instance:
Application foo written using Qt4 and application bar written using gtk2.
If any of qt4, gtk2, or the suil module that allows embedding gtk2 plugins in a qt4 application are missing, then the bar plugin cannot be loaded into the suil application.
Again sorry for not being clear: all hosts will require lv2core - this provides the host with the ability to determine what plugins are available (determines the plugin path, usually /usr/lib{%suffix}/lv2 or /home/suer/.lv2, reads the RDF metadata for info) and what inputs/outputs/control ports they require. It would then use suil to instantiate it
With these constraints, I think you were (unfortunately :-( right about the choices. You need all of the siul modules installed since you don't know what combination of toolkits the particular application and plugin combos the user is running will need. Filtering the dependencies shouldn't be too bad for the end user. The plugin and the application will pull in the correct UI toolkit libraries for the suil module to work. But as the packager you then have to manually track things that ordinarily are just a repoquery away.
I'm happy to manage it this way, I guess I will just have to mkae it very clear in the spec file for future maintainers.
You might be able to use BuildRequires with a specific version to help alert you to problems and that's not a proactive approach.
Good idea - in fact upstream recommend this and version suil accordingly (i.e. it is anticipated that multiple versions of suil may be installed, as this is suil-0 we've just used the package name 'suil' until now, we could use BuildRequires to further restrict it to the release)
packaging@lists.fedoraproject.org
-
Brendan Jones -
Toshio Kuratomi