Everywhere else that `conf.get('ENABLE_*')` is used as a boolean key for
something (for example in if statements) it always checks if == 1, but
in this one case it neglects to do so. This is important because
conf.get yields the same int that was stored, but if statements require
booleans.
So does executable's "install" kwarg, at least according to the
documentation. In actuality, it accepts all types without sanity
checking, then uses python "if bool(var)", so you can actually do
`install: 'do not'` and that's treated identical to `true`. This is a
type-checking bug which Meson will eventually fix.
muon fails on the same code, today.
Passing a file as a command argument in string form assumes that
run_command has the current subdir as its cwd, but Meson's documentation
*explicitly* calls this out as undefined and wrong to use.
Indeed, muon has a different implementation that uses a different cwd,
and this argument cannot be found. Instead, passing a files() object
means that it's the job of meson itself to verify the file exists, then
pass it to the run_command in some format that guarantees it is a valid
path reference.
When translations are disabled, it's not necessary to `import('i18n')`
and do nothing with it. Also, importing it is (slightly) slow as Meson
needs to load another implementation file from disk, so why bother with
that work?
More particularly, muon does not yet implement this module and fails to
setup. Since there's already an option to disable using it, it makes
sense to let that option completely skip the not-implemented
functionality and actually succeed.
Integers and booleans are supposed to be actual integers and booleans,
not strings describing their value, but Meson silently accepted either
one. It's still wrong to do it though, and other implementations of
Meson such as muon choke on it.
0 UID and GID are special, and should not be acceptable for the settings.
Hence, we can handle 0 as unset.
Strictly speaking, time epoch with 0 is valid, but I guess no one use
0 as a valid value.
Kubevirt is currently technically based on KVM (but not xen yet[1]).
The systemd-detect-virt command, used to differentiate the current
virtualization environment, works fine on x86 relying on CPUID, while
fails to get the correct value (none instead of kvm) on aarch64.
Let's fix this by adding a new 'vendor[KubeVirt] = kvm' classification
considering the sys_vendor is always KubeVirt.
[1] https://groups.google.com/g/kubevirt-dev/c/C6cUgzTOsVg
Signed-off-by: Fei Li <lifei.shirley@bytedance.com>
