GNOME Bugzilla – Bug 765183
Add 'jack' variant that builds JACK elements
Last modified: 2016-05-15 21:48:09 UTC
Created attachment 326210 [details] [review] patch that allows to build JACK elements with Cerbero I have created a patch that allows to build JACK elements with Cerbero.
Review of attachment 326210 [details] [review]: ::: recipes/gst-plugins-good-1.0.recipe @@ +132,3 @@ + if self.config.variants.jack: + self.deps += ['jack'] You also need to add jack to the dependencies of the package that ships the plugin ::: recipes/jack.recipe @@ +3,3 @@ + +class Recipe(recipe.Recipe): + name = 'jack' Having a jack recipe does not seem ideal. It will potentially conflict with any version that is already available on the system. It might be better to just depend on jack in bootstrap ::: recipes/libsndfile.recipe @@ +2,3 @@ + +class Recipe(recipe.Recipe): + name = 'libsndfile' With this we can also enable the sndfile plugin in gst-plugins-bad. FWIW, it would be best to have each new recipe as a single commit and then another commit that adds the jack variant and uses it in gst-plugins-good.
I disagree with potential conflict issue. You can say the same thing about any library that is built via Cerbero but for some reason you still build them instead of bootstrapping. This approach allows also to bundle JACK libs with package which, at least in my case, is the whole point of using Cerbero, so actually I can not care what is in the system as package I deliver contains everything that is needed to run the app. Please correct me if my reasoning is wrong. I will add JACK dependency to the appropriate package, and split commit into separate ones, one per recipe.
(In reply to Marcin Lewandowski from comment #2) > I disagree with potential conflict issue. You can say the same thing about > any library that is built via Cerbero but for some reason you still build > them instead of bootstrapping. Jack is a server, not a library. That helper library must match the server version. Because of that, it is a totally different reasoning then when we integrate libraries. Note that if you want to use cerbero to build part of you base system, you are free to do so. There is config called "external_recipes" that you may use. config.external_recipes = {'test1': ('/path/to/repo', 1), 'test2': ('/path/to/other/repo', 2)} > > This approach allows also to bundle JACK libs with package which, at least > in my case, is the whole point of using Cerbero, so actually I can not care > what is in the system as package I deliver contains everything that is > needed to run the app. Again bundling the library without anything to run the matching server is not ideal. > > Please correct me if my reasoning is wrong. :-D > > I will add JACK dependency to the appropriate package, and split commit into > separate ones, one per recipe. Thanks !
Hello, I understand your point. My point is however, to bundle JACK with package to not worry about what comes with the OS. The patch that I made allows to ship also JACK daemon which would lead to consistent daemon/library version. It's up to you to decide what to do next. I would prefer to merge this with GStreamer as maintaining forks of Cerbero is a pain (see bug #765852) but if you prefer to keep that separate I can always use external_recipes.
Thanks for the patch, but I think the consensus on our end is that we don't want to support and maintain this in our cerbero repo, sorry :) I think realistically you'll have to maintain your own cerbero fork/branch for anything non-trivial anyway.
Ok, thanks. Can you just please guide me how to do this properly? After installing libjack*-dev on the build machine, compilation works fine, but when packaging happens I end up with error similar to bug #766380.