[Bug 795107] New: Meson: missing option to enable/disable plugins

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=795107

            Bug ID: 795107
           Summary: Meson: missing option to enable/disable plugins
    Classification: Platform
           Product: GStreamer
           Version: 1.12.x
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: common
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: xclaesse at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

There is currently no way with meson to select which plugins to enable/disable.
We should add them in meson_options.txt. This could require new feature from
meson itself if we want three-state options enabled/disabled/auto like we have
with autotools.

I'm opening this bug report to start discussion and define a plan of what we
ideally want. If we know what we want, I'm sure we can get support from Meson
easily.

In autotools there are currently different types of options, I've spotted them:
- AC_ARG_ENABLE / AC_ARG_WITH
- AG_GST_CHECK_FEATURE
- AG_GST_CHECK_PLUGIN
- AG_GST_CHECK_SUBSYSTEM_DISABLE

For what I understood we would need this:
- For each dependency-less plugins, add option('pluginname', type: 'boolean',
value: true). I don't think we need a three-state value here, they should all
be built by default and could be disabled explicitly.
- For each plugin with external dep, add a three-state option. 'enabled' means
build fails if dep is not found, 'disabled' means we never build it regardless
of the dep, 'auto' means build it if dep is found, otherwise just skip that
plugin.
- Features are a set of plugins with dependencies that can be enabled/disabled
as a group, instead of individually, right? I guess that needs a three-state
option too.

Note that nowadays GNOME guideline discourage "auto" options, better make
things explicit. I tend to agree that the set of plugins that gets built
shouldn't be a surprise. The default value could be true for everything unless
the plugin/feature is considered too experimental or niche use-case.

We could also go with just 2 string array options to list enabled/disabled
plugins (or 3rd list for auto plugins). It has the advantage to be easier, a
list of plugins used is often what users has. It has the disadvantage to be too
free-form and requires validate that strings correspond to a plugin that
actually exists.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.