RFC: Ship GLib bindings as part of GStreamer inside GStreamer's namespace
I would love to see in the nearest future GStreamer providing NuGet packages ready-to-use as part of the official release process.
For that to happen, several things need to be improved on the way:
- Make GstSharp bindings work with other nugets proving depeding or providing GLib bindings
- Provide NuGet binary packages:
- GstSharp.win32_x86_64
- GstSharp.osx_x86_64
- GstSharp.linux_arm
- etc ...
- Automate NuGet packages with cerbero
The first stone in the road is the GLib's bindings situation:
- There are several forks of Glib's bindings
- Forks are not compatible between them
- Within the same Fork, versions are not backwards compatible
- GstSharp needs a very specific version of glib-sharp
- GstSharp NuGet packages its own version of glib-sharp
The biggest issue here is that releases of glib-sharp are not backwards compatible, which means that 2 projects depending on glib-sharp can't work together, since only one version of the glib-sharp will be loaded.
This an example where things can go wrong:
- I create a new MyGtkPlayer project
- I add as dependencies GstSharp and GtkSharp
- GtkSharp depends on GlibSharp providing a version of glib-sharp
- GstSharp provides its own version of glib-sharp
- The application will load one of the 2 assemblies
- BOOM!
Renaming the assembly glib-sharp.dll to gstreamer-glib-sharp.dll will not work either, since it will provide the same GLib clases in the same GLib namespace.
For all these reasons GstSharp needs to ship its own version of GLib and it has to be done with a namespace different than GLib
Possible solutions:
- Use ILMerge with a namespace prefix. This will weave the generated gstreamer-sharp.dll and merge glib-sharp and gio-sharp into the final assembly, creating an internal copy of GLib that is not exposed.
- Import GtkSharp sources in gstreamer-sharp, rename the namespace to GStreamer.GLib. This will ease maintenace a lot, since fixes in GtkSharp are directly done in gstreamer-sharp's repo