Compiling a gst-plugins-rs package with local (modified) gstreamer-rs files

Application Development Build issues
1

I’ve cloned gstreamer-rs and gst-plugins-rs. I’d like to make some changes to both and use them together to build gst-plugin-spotify from gst-plugins-rs. I am able to build a clean checkout of gst-plugins-rs and gstreamer-rs, but when I change gst-plugins-rs/Cargo.toml to point to my local gstreamer-rs clone, I get loads of compile errors. I’m not sure I am using the correct method to do this:

diff --git a/Cargo.toml b/Cargo.toml
index ce7dfae8..62af7cd2 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -133,7 +133,8 @@ gtk = { package = "gtk4", git = "https://github.com/gtk-rs/gtk4-rs", branch = "m
 gdk-wayland = { package = "gdk4-wayland", git = "https://github.com/gtk-rs/gtk4-rs", branch = "master"}
 gdk-x11 = { package = "gdk4-x11", git = "https://github.com/gtk-rs/gtk4-rs", branch = "master"}
 gdk-win32 = { package = "gdk4-win32", git = "https://github.com/gtk-rs/gtk4-rs", branch = "master"}
-gst = { package = "gstreamer", git = "https://gitlab.freedesktop.org/gstreamer/gstreamer-rs", branch = "main" }
+gst = { package = "gstreamer", path = "../gstreamer-rs/gstreamer" }
 gst-app = { package = "gstreamer-app", git = "https://gitlab.freedesktop.org/gstreamer/gstreamer-rs", branch = "main" }
 gst-audio = { package = "gstreamer-audio", git = "https://gitlab.freedesktop.org/gstreamer/gstreamer-rs", branch = "main" }
 gst-base = { package = "gstreamer-base", git = "https://gitlab.freedesktop.org/gstreamer/gstreamer-rs", branch = "main" }

~/Dev/gst-plugins-rs$ cargo build --package gst-plugin-spotify
Skipping git submodule https://github.com/gtk-rs/gir due to update strategy in .gitmodules
Skipping git submodule https://github.com/gtk-rs/gir-files due to update strategy in .gitmodules
Skipping git submodule https://gitlab.freedesktop.org/gstreamer/gir-files-rs.git due to update strategy in .gitmodules
Skipping git submodule https://github.com/gtk-rs/gir due to update strategy in .gitmodules
Skipping git submodule https://github.com/gtk-rs/gir-files due to update strategy in .gitmodules
Skipping git submodule https://github.com/gtk-rs/gir due to update strategy in .gitmodules
Skipping git submodule https://github.com/gtk-rs/gir-files due to update strategy in .gitmodules
Skipping git submodule https://github.com/gtk-rs/gir due to update strategy in .gitmodules
Skipping git submodule https://github.com/gtk-rs/gir-files due to update strategy in .gitmodules
Compiling gstreamer v0.22.4 (/home/nicky/Dev/gstreamer-rs/gstreamer)
Compiling gst-plugin-spotify v0.13.0-alpha.1 (/home/nicky/Dev/gst-plugins-rs/audio/spotify)
error[E0659]: ObjectSubclass is ambiguous
→ audio/spotify/src/spotifyaudiosrc/imp.rs:82:6
|
82 | impl ObjectSubclass for SpotifyAudioSrc {
| ^^^^^^^^^^^^^^ ambiguous name
|
= note: ambiguous because of multiple glob imports of a name in the same module
note: ObjectSubclass could refer to the trait imported here
→ audio/spotify/src/spotifyaudiosrc/imp.rs:17:5
|
17 | use gst::subclass::prelude::;
| ^^^^^^^^^^^^^^^^^^^^^^^^^
= help: consider adding an explicit import of ObjectSubclass to disambiguate
note: ObjectSubclass could also refer to the trait imported here
→ audio/spotify/src/spotifyaudiosrc/imp.rs:18:51
|
18 | use gst_base::subclass::{base_src::CreateSuccess, prelude::};
| ^^^^^^^^^^
= help: consider adding an explicit import of ObjectSubclass to disambiguate

error[E0659]: ObjectImpl is ambiguous
→ audio/spotify/src/spotifyaudiosrc/imp.rs:89:6
|
89 | impl ObjectImpl for SpotifyAudioSrc {
| ^^^^^^^^^^ ambiguous name
|
= note: ambiguous because of multiple glob imports of a name in the same module
note: ObjectImpl could refer to the trait imported here
→ audio/spotify/src/spotifyaudiosrc/imp.rs:17:5
|
17 | use gst::subclass::prelude::*;
| ^^^^^^^^^^^^^^^^^^^^^^^^^
= help: consider adding an explicit import of ObjectImpl to disambiguate

etc etc etc.

I’ve tried the main branch of gstreamer-rs and also tried switching to the 0.22 (shown above) but I get the same problem. What am I doing wrong here?

2

That happens because now you pull in two versions of the gstreamer crate: one from your local path, and one indirectly via e.g. gstreamer-audio from the original path.

Check the cargo docs for how to do this correctly.

3

I tried the exact same thing using patch and got the same failure. Am I supposed to specify the local path for every single one of the gstreamer-rs packages? That worked but seems clunky.

4

I’ve (re)read the docs and to be honest I don’t understand why doing this via a new [patch] section is considered more correct than modifying the existing [workspace.dependencies] section. Either way I am messing around with my Cargo.toml, but I’m no expert and I’ll go along with it. I just want it to work so I can get on.

It seems my actual problem was I also needed to point the gstreamer-base package to point to my local copy. Just doing the one package I changed wasn’t enough, but adding -base also is. For some reason, I couldn’t use gst = and gst-base = like in the [workspace.dependencies] section, it had to be gstreamer = and gstreamer-base =. I’ve no idea why. None of this is very obvious but these are Rust language issues.

[patch."https://gitlab.freedesktop.org/gstreamer/gstreamer-rs"]
gstreamer = {path = "../gstreamer-rs/gstreamer" }
gstreamer-base = {path = "../gstreamer-rs/gstreamer-base" }

EDIT:
Maybe a better way is to create a gst-plugins-rs/.cargo/config.toml containing just my patch section. Although I still have to make sure I don’t add that new file by accident when working (or ignore it).#

EDIT2:
I can move that .cargo/config.toml into the parent directory (and use absolute paths for sanity) so it’s not tracked by the gst-plugins-rs git repo. So that’s nice, until I forget I’ve done this and wonder why I can’t get the latest version.

1 Like
5

Yes, you need to list all of them unfortunately. I’m not aware of another solution to this and it’s a bit annoying whenever I need it :slight_smile: Maybe you want to bring that up in the cargo issue tracker on github in case a more convenient solution can be found.

1 Like
6

It’s a real mess what they’ve got to be honest. Turns out, any features you specify in your [patch] section are silently (!!) ignored and you must edit the original [dependencies] section to make those sorts of changes. This bug has existed in some form or another since 2016. I can’t find the documentation for this but there are a bunch of bug reports, none of which solving anything. Why they’d introduce a mechanism that only half works I have no idea… In this case, I think probably better off just editing the original [dependencies] section so it’s all in one place.

1 Like