RFC: Should gstreamer automatically fallback to all possible subprojects?
Lately I had conversations about usage of "auto" features in GTK, and that made me think we could want to revisit a bit our usage in GStreamer.
When no dependency is available on the system, e.g. on Windows, that makes a lot of subprojects, some of which are unlikely to be useful. For example here is the list when leaving everything to "auto" on Windows. That list continually grows while more projects are being ported to Meson.
Subprojects
FFmpeg : YES 21 warnings
cairo : YES 5 warnings
dssim : NO C shared or static library 'm' not found
dv : YES 1 warnings
expat : YES 1 warnings
fontconfig : YES 12 warnings
freetype2 : YES 1 warnings
fribidi : YES 2 warnings
gi-docgen : NO C:\Python38\python is missing modules: jinja2, markdown, markupsafe, pygments, toml, typogrify
gl-headers : YES
glib : YES 18 warnings
glib-networking : NO Problem encountered: No TLS backends enabled. Please enable at least one TLS backend
gobject-introspection : YES 10 warnings
graphene : NO
Value "false" (of type "string") for combo option "Enable GObject Introspection (depends on GObject)" is not one of the choices. Possible choices are (as string): "enabled", "disabled", "auto".
gst-devtools : YES 11 warnings
gst-editing-services : YES 4 warnings
gst-examples : YES
gst-integration-testsuites: YES
gst-libav : YES 1 warnings
gst-omx : NO Feature 'omx' disabled
gst-plugins-bad : YES 6 warnings
gst-plugins-base : YES 41 warnings
gst-plugins-good : YES 52 warnings
gst-plugins-rs : NO Feature 'rs' disabled
gst-plugins-ugly : YES 6 warnings
gst-python : YES 2 warnings
gst-rtsp-server : YES 2 warnings
gstreamer : YES 14 warnings
gstreamer-sharp : NO Feature 'sharp' disabled
gstreamer-vaapi : NO Feature 'vaapi' disabled
gtest : YES
harfbuzz : YES 12 warnings
json-glib : YES 18 warnings
libffi : YES 1 warnings
libmicrodns : YES 1 warnings
libnice : NO Problem encountered: Either GnuTLS or OpenSSL is required as crypto library, but neither was found
libopenjp2 : NO C shared or static library 'm' not found
libpng : YES 1 warnings
libpsl : YES 1 warnings
libsoup : YES 8 warnings
libxml2 : YES 2 warnings
openh264 : YES 8 warnings
openssl : NO Neither a subproject directory nor a openssl.wrap file was found.
opus : YES 1 warnings
orc : YES 5 warnings
pango : YES 7 warnings
pixman : YES 1 warnings
proxy-libintl : YES 2 warnings
pycairo : YES 3 warnings
pygobject : YES 6 warnings
sqlite : YES 1 warnings
tinyalsa : NO Neither a subproject directory nor a tinyalsa.wrap file was found.
win-flex-bison-binaries : YES
win-nasm : YES
x264 : YES 2 warnings
zlib : YES 1 warnings
Currently if an external dependency is missing and a subproject is available we always build the subproject. Typically with code like that:
dep = dependency('foo',
required: get_option('foo'),
fallback: ['foo', 'foo_dep'],
)
I'm wondering if some of those should rather only fallback if the corresponding option is explicitly set to enabled
by the user. From a meson POV, that can be done by using the new [provide]
section in the .wrap file and omit the fallback
argument (we should do that anyway).
# This returns not-found when option is 'auto' and use subproject when option is 'enabled'.
dep = dependency('foo', required: get_option('foo'))
If we want to use the subproject by default, can use either allow_fallback: true
or fallback: 'foo'
syntax.
That could be the time to revisit what we want to build by default? Everything? Nothing? Just the selected subset?