[3.0] vlc_modules: add an API to get the shortcut to use with a module

3.0 version of !5671 to fix #28691

The review should be done on this branch as depending on what is possible for 3.0 we will do it on 4.0 (or not). In particular I'm not sure we can add an API entry to libvlccore in VLC 3. Or maybe I'm doing it wrong.

---

A plugin may contain multiple modules. They all have the same first shortcut which is the VLC_MODULE_NAME [1]. Then if there's a shortcut (or more) it's further in the list.

module_get_object() cannot differentiate between the modules inside a plugin. It should keep returning the name of the VLC_MODULE_NAME. But we need another API to get the proper shortcut to use.

[1] https://code.videolan.org/videolan/vlc/-/blob/2c6d9de9f66aefb639ac8f00af7b030760cce294/src/modules/entry.c#L292

Plus a small backport to remove a warning during build.

changed milestone to %3.0.x maintenance

added Component::Core Severity::major labels

mentioned in merge request !5671

added 4 commits

• baff84f6 - modules: move documentation to header
• 17a88e77 - vlc_modules: add an API to get the shortcut to use with a module
• c403d735 - qt: use the shortcut of filters to add them to the filter string
• 77c26b98 - npapi: Fix warning during autoreconf

Compare with previous version

I think we can add a new API for that particular case. Cc @jbk @Courmisch

added MRStatus::Acceptable label

Adding APIs to VLC 3.x requires a version bump and to update vlc_plugin.h

# define MODULE_SYMBOL 3_0_0f
# define MODULE_SUFFIX "__3_0_0f"

You cannot have plugins depend on an API that didn't exist in 3.0.0f without updating that.

Yeah, I thought there would be something like that.

So is it a change we want ? Alternatively a workaround can be done in module_get_object() particularly for d3d11_filters. But I'm not sure of the consequences on the rest of the code if we don't read the VLC_MODULE_NAME.

I'm not sure MODULE_SYMBOL is the right thing to change though. I think that might be the ABI of the plugin descriptor. In this case it's not changed. Only the libvlccore API+ABI changes. We may just need to bump the libvlccore version as in !2088 (merged) for 3.0.18.

Maybe (not sure, I have to admit that it's not a part with which I'm very familiar).

According to this thread we can bump the minor version if we make "backwards compatible ABI release". Although I'm not sure if we need to put the new entry at the end of the symbol file.

As for the libtool versioning guide, it's here: https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html. We would be in case 4:

If any interfaces have been added, removed, or changed since the last update, increment current, and set revision to 0.

And also the futher explanation 2:

Programs using the previous version may use the new version as drop-in replacement, but programs using the new version may use APIs not present in the previous one. In other words, a program linking against the new version may fail with “unresolved symbols” if linking against the old version at runtime: set revision to 0, bump current and age.

That means it would be bump to 10:1:1

You can add a new symbol to libvlccore if you bump CURRENT and AGE, and reset REVISION. But:

1. You cannot use a same or larger CURRENT than following versions. The libtool versioning system is really brain-dead, as this is not an issue with the native GNU/Linux SO versioning.
2. You cannot use the new symbol in plugins that target a baseline VLC plugin ABI of 3.0.0f, at least on platforms where missing symbols halt the process.

In other words, we can add symbols but we can't use them...

added MRStatus::InReview label and removed MRStatus::Acceptable label

Closing this in favor of the hackish !5676 (merged) version.

closed