Let's a "b" helper for json_variant_set_field() that combines
json_build() with json_variant_set_field(), similar to the
json_variant_merge_objectb(), json_variant_append_arrayb().
json_append() is a useful wrapper around json_variant_merge(). However,
I think the naming sould be cleaned up a bit of both functions.
I thinker "merge" is the better word than "append", since it does
decidedly more than just append: it replaces existing fields of the same
name, hence "merge" sounds more appropriate. This is as opposed to the
similar operations for arrays, where no such override logic is applied
and we really just append, hence those functions are called "append"
already.
To make clearer that "merge" is about objects, and "append" about
arrays, also include "object" in the name.
Also, include "json_variant" in the name, like we do for almost all
other functions in the JSON API that take a JSON object as primary
input, and hence are kinda object methods.
Finally, let's follow the logic that helpers that combine json_build()
with some other operation get suffixed with "b" like we already have in
some cases.
Hence:
json_variant_merge() → json_variant_merge_object()
json_append() → json_variant_merge_objectb()
This mirrors nicely the existing:
json_variant_append_array()
json_vairant_append_arrayb()
This also drops the variant of json_append() that takes a va_arg
parameter (i.e. json_appendv()). We have no user of that so far, and
given the nature as a helper function only I don#t see that happening,
and if it happens after all it's trivial to bring back.
Let's make utf8_to_utf16() and utf16_to_utf8() a bit nicer to use by
adding shortcuts for common cases.
This is particularly relevant for utf16_to_utf8() since the
multiplication with 2 is easy to forget.
This reverts commits 89e73ce86f and
543d2a4d45.
The commit assign "custom" to fixed DUID type 5. When making DUID fully
configurable, the type number should be also configurable. Also, the
fully custom DUID should be acceptable for DHCPv4.
We went back-and-forth a bit on this. Very old meson would print a message
about detecting the program if a quoted argument was used, leading to a lot of
noise. So we started to convert various places to use the variable, but then it
turned out that meson < 0.56.2 doesn't handle this correctly and we reverted to
using strings everywhere in 7c22f07cbd. Then at
some point we stopped supporting old meson and over time we started using the
variable in various places again, somewhat inconsistently. Then most calls to
'sh' were removed in 9289e093ae when
install_emptydir() builtin started being used.
Now meson allows either the string or variable to be used, and doesn't print a
message if the string is used. Let's use the variable everywhere. For 'sh', we
could do either, but for other variables, we _do_ want the detection to happen,
for example for git, find, awk, which might not be installed and we want to
detect that early, before we start the build. It would be ugly to use quotes
for some programs, but not for others. Also, a string is still refused for
test(), so we couldn't use the string version even if we didn't care about
detection.
Now that we use meson feature options for our dependencies, we can just
rely on '--auto-features=disabled' to do the same. One benefit of this
is that specific features can still be force-enabled by overriding it
with the appropriate '-Dfeature=enabled' flag.
The two remaining uses for skip-deps can simply rely on their default
logic that sets the value to 'no' when the dependency is disabled.
Dan Streetman
Zbigniew Jędrzejewski-Szmek
Yu Watanabe
Lennart Poettering
Susant Sahani
Daan De Meyer
Frantisek Sumsal
Jan Janssen