The load functions used to do 3 things:
- push the sandbox function on the stack
- load the file and push it as a function on the stack
- call the sandbox (or the file)
Now there are separate functions to do these 3:
- wplua_push_sandbox
- wplua_load_*
- wplua_pcall
-some modules will not be available during runtime, due to
external dependencies.
-these modules can now be marked optional.
-loading of these optional modules will be attempted and if
they are not available, wp will recover and will not be
terminated.
* Make the flags public and give them nicer names
* Pass down the flags from the caller, so the caller can now explicitly
ask for looking into specific directories
* Rename the methods
* Remove and inline the wp_get_xdg_config_dir() method, since it's only
used internally
* Refactor the lookup dirs ordering to get both WIREPLUMBER_*_DIR env
variables to replace all the other directories. Previously, we were looking
for scripts in WIREPLUMBER_DATA_DIR, but we were also looking in /etc at
the same time (with precedence, even), which could result in unexpected
behaviour. Now, if a WIREPLUMBER environment variable is specified,
we only look in there.
This also corrects the logic of loading config files in m-lua-scripting.
Previously, if an error occured within the iteration function,
the error was not properly propagated to the caller because -EINVAL
was being added to nfiles instead of checked.
The previous approach to loading config files was to ask WP for the
directory and then search those for the config files. This patch changes the
approach - a caller now asks WP to search for a specific config file or
iterate over a config file directory.
This allows us to implement a directory lookup order, i.e.
"wireplumber.conf" may be in XDG_CONFIG_DIR, /etc/,
/usr/share and the first one found is used.
For configuration directories, the new method iterates over all matching
entries (files + directories) and invokes a callback for each entry.
This enables distributions to ship default files in /usr/share/wireplumber
but have admins and users override them on a local basis. For lua scripts in
particular, overriding a distribution-provided file with an empty file
effectively disables it, adding a file adds it in the right sort order.
From the g_file_test documentation:
"For example, (G_FILE_TEST_EXISTS | G_FILE_TEST_IS_DIR) will return TRUE if
the file exists; the check whether it's a directory doesn't matter since the
existence test is TRUE. With the current set of available tests, there's no
point passing in more than one test at a time."
There is no real use for groups in our API. Just use the name of
the file as the default group and be done with it...
Storing multiple groups with this API is problematic because it
forces flushing the file to disk multiple times, one for each group,
and it's just more performant if we use a prefix in the keys
to implement some form of logical separation.
This commit also makes the GKeyFile a temporary object. As we
always load the file from the file system in _load()
and we always replace its contents with a new dictionary in _save(),
there is no point in keeping the keyfile's internal data structures
stored in memory.
Save errors are now also propagated to adhere to the programming
practices of GObject
We have ended up not using them, so let's not carry them
in the ABI of 0.4
We can always revert that, but let's first decide how
these objects should be used
Plugin() is confusing because it's not a constructor, it just finds
an existing instance of a plugin object. All other camel-case
functions are constructors in the current lua API.
