280610 2024-09-30 04:32:35 -0700 [GLib] Centralize handling of environment variables 2024-09-30 05:21:05 -0700 1 1 1 Unclassified WebKit Platform Other Unspecified Unspecified NEW https://bugs.webkit.org/show_bug.cgi?id=192405 P2 Normal --- 1 aperez webkit-unassigned bugs-noreply cgarcia fujii oldest_to_newest 2064200 0 aperez 2024-09-30 04:32:35 -0700 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 =) 2064209 1 aperez 2024-09-30 05:03:52 -0700 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. 2064210 2 aperez 2024-09-30 05:11:50 -0700 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 ;-) 2064213 3 fujii 2024-09-30 05:21:05 -0700 JSC has https://github.com/WebKit/WebKit/blob/main/Source/JavaScriptCore/runtime/OptionsList.h