$ find * -type f |xargs perl contrib/scripts/spdx.pl $ git rm contrib/scripts/spdx.pl
The enum values are unique throughout the source code so they can easier be searched (e.g. with grep), compared to '\0'. It is often interesting where a certain modifier is used, so searching the source code is important to give relevant results. Also, the modifier is really an enum and we shouldn't misuse char type. If that would be a good idea in general, we wouldn't need any enums at all. But we use them for good reasons.
No notable change in behavior, but makes more sense this way.
"libnm-core" implements common functionality for "NetworkManager" and
"libnm".
Note that clients like "nmcli" cannot access the internal API provided
by "libnm-core". So, if nmcli wants to do something that is also done by
"libnm-core", , "libnm", or "NetworkManager", the code would have to be
duplicated.
Instead, such code can be in "libnm-libnm-core-{intern|aux}.la".
Note that:
0) "libnm-libnm-core-intern.la" is used by libnm-core itsself.
On the other hand, "libnm-libnm-core-aux.la" is not used by
libnm-core, but provides utilities on top of it.
1) they both extend "libnm-core" with utlities that are not public
API of libnm itself. Maybe part of the code should one day become
public API of libnm. On the other hand, this is code for which
we may not want to commit to a stable interface or which we
don't want to provide as part of the API.
2) "libnm-libnm-core-intern.la" is statically linked by "libnm-core"
and thus directly available to "libnm" and "NetworkManager".
On the other hand, "libnm-libnm-core-aux.la" may be used by "libnm"
and "NetworkManager".
Both libraries may be statically linked by libnm clients (like
nmcli).
3) it must only use glib, libnm-glib-aux.la, and the public API
of libnm-core.
This is important: it must not use "libnm-core/nm-core-internal.h"
nor "libnm-core/nm-utils-private.h" so the static library is usable
by nmcli which couldn't access these.
Note that "shared/nm-meta-setting.c" is an entirely different case,
because it behaves differently depending on whether linking against
"libnm-core" or the client programs. As such, this file must be compiled
twice.
(cherry picked from commit af07ed01c04867e281cc3982a7ab0d244d4f8e2e)
It will be useful to extend nm_utils_strsplit_set() with various flavors and subtly different behaviors. Add a flags argument to support these.
I find it questionable, how nmcli likes to coerce the empty input to
NULL to indicate resetting the value. If nmcli would like to set a
default, it should use a different way of signalling that. Anyway, the
assertion was too strict.
$ nmcli connection modify "$PROFILE" +ipv4.addresses ''
Setting one property might affect multiple properties. For example, setting a team property might also emit property changed signal for "team.config". Or, one property might be modified multiple times. For example list properties may first clear the property, then append multiple elements. Or a list property might remove multiple elements. Combine these signals via g_object_freeze_notify() and g_object_thaw_notify().
set_fcn() and remove_fcn() are strongly related. They should accept arguments in the same format, hence the parsing of the arguments should be done at one place. In fact, previously the parsing was separate, leading to ugly inconsistencies: $ nmcli connection modify "$PROFILE" +vpn.data x=y $ nmcli connection modify "$PROFILE" -vpn.data x=y Error: failed to remove a value from vpn.data: invalid option 'x=y'. or $ nmcli connection modify "$PROFILE" +ipv4.addresses 192.168.1.5/24,192.168.2.5/24 $ nmcli connection modify "$PROFILE" -ipv4.addresses 192.168.1.5/24,192.168.2.5/24 Error: failed to remove a value from ipv4.addresses: invalid prefix '24,192.168.2.5/24'; <1-32> allowed. Let set_fcn() handle set-default, set-all, add, and subtract.
Previously, set_fcn() could only append values. Now, pass on the modifier so that it may append, set all, or reset the default. These operations are strongly related and should be handled by the same set_fcn() function.