Bug 280610 – [GLib] Centralize handling of environment variables

• Status: NEW
• Component: Platform

[Adrian Perez]

In the GLib (WPE + GTK) ports we have a number of toggles and tweaks that may
be applied at runtime using environment variables. While mostly intended for
development, end-users are asked sometimes to use them for complementing bug
reports and/or trying workarounds for their issues.

Currently, each call site which makes use of an environment variable handles
reading the environment variable and parsing, resulting in code duplication
and lack of consistency, e.g. some locations will accept "0" and "1" as boolean
flags, others "0" and any non-zero value; and error-checking also varies wildly.

We would like to have a WTF::Environment (or similarly named) class defining
the base structure and common code used to get and parse environment variable
values. An additional YAML source file would describes which environment
variables are available, the types of the values they accept, what are their
default values if undefined (or cannot be parsed), and an optional short
description. Then, we would generate C++ code from the YAML file that adds
getter functions to the Environment class.

If the above sounds familiar, it's because the idea is inspired by how
“Source/WTF/Scripts/Preferences/UnifiedWebPreferences.yaml” is used to
describe feature flags =)

[Adrian Perez]

I am aware of bug #192405 where there was been a previous attempt at
doing something similar. Contrary to that attempt, I'd say we want to
have a smaller scope but approach things in a different way:

 - Cover only the GLib ports. Other ports may want to adopt the mechanism,
   but we would rather have something earlier and help out later

 - Only handle *getting* values from the environment. All of them
   would be read and parsed at once as soon the Environment instance
   is created, defaults applied, and warnings emitted on stderr for
   invalid values.

 - Avoid using strings and parsing on each callsite, whenever possible,
   solved by generating the accessors from the YAML description. This is
   one more reason to have the types declared in the YAML.   

 - Avoid each callsite having to handle the case where a variable
   is not defined in the environment. If a default value is declared
   in the YAML source, then use it as fallback (like in the example
   above):

     // Default value used if not present in the environment.
     bool useTimer = Environment::singleton().WEBKIT_FORCE_VBLANK_TIMER;

   If there is no default then the type is wrapped in std::optional, e.g.

     // No default value declared in the YAML description.
     if (auto address = Environment::singleton().WEBKIT_INSPECTOR_SERVER)
         WTF_ALWAYS_LOG("Env var was defined, value: " << *address);

 - Start porting over a few uses of [g_]getenv() to the new mechanism,
   and then incrementally port more code, instead of trying to solve all
   cases in one go.

[Adrian Perez]

Ah, and with the describe-in-YAML-then-generate we could also produce
documentation automatically, and have things like this page from the
old wiki always up-to-date:

   https://trac.webkit.org/wiki/EnvironmentVariables

;-)

[Fujii Hironori]

JSC has https://github.com/WebKit/WebKit/blob/main/Source/JavaScriptCore/runtime/OptionsList.h