"nm-value-type.h" is a header-only file, as it contains only small
accessors that should be inlined.
As such, the implementation of these functions is guarded by "#ifdef
NM_VALUE_TYPE_DEFINE_FUNCTIONS", so that one can use this header (and
NMValueType enum) with less overhead (at compile time).
Glib has GValue which used for boxing value.
Add NMValueType enum, which has a similar purpose, but it's much more
limited.
- contrary to GValue, the type must be tracked separately from the
user-data. That is, the "user-data" is only a pointer of appropriate
type, and the knowledge of the actual NMValueType is kept separately.
This will be used to have a static list of meta-data that knows the
value types, but keeping the values independent of this type
information. With GValue this would not be possible.
- the use case is much more limited. Just support basic integers,
boolean and strings. Nothing fancy.
Note that we already do something similar at muliple places. See for
example NMVariantAttributeSpec and nm_utils_team_link_watcher_to_string().
These could/should instead use NMValueType.
When we link static libraries together, there must be no duplicate
symbols.
Since we have a lot of static/intermediate libraries, getting this right
is complicated and sometimes leads to ugly solutions.
As a new rule: don't let static libraries link with other static
libraries. Only binaries and libnm/libnm.la should explicitly link
with all the static libraries that they require.
There are exceptions: "src/libNetworkManager.la" and "libnm/liblibnm.la".
These are static, internal libraries, but they are basically *everything*
that ends up in "src/NetworkManager" and "libnm/libnm.la", respecitively.
Hence, these static libraries also link against other static libraries.
Another exception to this rule is "src/libNetworkManagerTest.la", for
similar reasons.
We compile src/main.c as part of src/NetworkManager. Explicitly link with
glib, because that is required by the source code. Apparently, it also
works without this, but still do it for correctness.
Now that unit tests no longer dynamically link against libnm/libnm.la,
and statically against the same code, we can enable this assertion
again.
This reverts commit 7a0e347b38.
We have "src/libNetworkManager.la" which is an intermediate static
library containing everything that ends up in "src/NetworkManager".
Likewise, add "libnm/liblibnm.la" to be the static library that contains
everything from "libnm/libnm.la".
The point of these libraries is to tie everything together that is used
by "src/NetworkManager" and "libnm/libnm.la" so that it also can be used
by unit-tests. Thereby, the unit tests will link statically against the
code of libnm. The problem is that the unit tests also want to access
internal functionality of libnm that is not accessible when dynamically
linking.
In part, this new library replaces "libnm/libnm-utils.la". The previous
name was confusing, because to us everything is an "utils", and it's
unclear what the purpose of that library was. Now the purpose should be
a bit clearer: liblibnm.la is a step before libnm.la, similar to what
libNetworkManager.la is to NetworkManager.
It doesn't have to be at the end of line, there may be more words
following.
Fixes: d66a1ace23 ('contrib/checkpatch: avoid command injection in checkpatch.pl script')
If we created a software interface it is because we already decided
that it should be managed, and so there is no point in waiting udev to
check that the interface is not udev-unmanaged.
We still wait udev for software interfaces created externally.
An active connection started by user could be queued in state UNKNOWN
which means the device hasn't started activating yet. Eventually it
will, and we don't want to cancel the user activation because of an
internal autoconnection attempt.
There was a special case for ensuring that the device's configuration
doesn't disappear when some factory is too late at recognizing the
device is just a component of another one.
It was always a bad idea. If the device already had an active
connection (such as for a generated default wired connection), it would
remain around, with a dangling reference to the device.
This effectively reverts commit 5ad69cb29b ('core: remove child devices
without deconfiguring them (bgo #738479)'). It's okay to do so, because
we now wouldn't deconfigure the device upon its removal anyway.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/151/
The pid-file is private to NetworkManager. It should reside in NetworkManager's
run directory instead of "/var/run".
I don't think that changing this location can break existing uses. Why
would somebody outside of NetworkManager care about this file?
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/157
Rename tests so that they have unique names.
meson requires that the build executables have unique names (at least,
older versions). Hence, we used to name the test binary different from
the source file ("libnm-test-general" vs. "test-general.c").
The tests should be named "*/tests/test-*", and the source file should
have the same name as the test executable.
Rename the sources so that the names are unique.
For the most part, we only have one main .gitignore file.
There were a few nested files, merge them into the main file.
I find it better to have only one gitignore file, otherwise the
list of ignored files is spread out through the working directory.
We already have "libnm-core/tests/test-keyfile.c" from which we build
"test-keyfile".
Our test binaries should be named the following:
- "*/tests/test-*"
- the test binary "*/tests/test-*" should be build from a source file
"*/tests/test-*.c". Meaning: the source's and executable's name should
correspond.
- test binaries should be named uniquely. Also, because older meson
versions don't like having the same binary name more than once.
Rename to avoid the duplicate name.
Older versions of meson don't like building multiple artifacts
with the same name (even if they are in different directories). We
have multiple tests called "test-general.c", and it would be natural
to compile a test binary of the same name.
Meson encountered an error in file src/tests/meson.build, line 14, column 2:
Tried to create target "test-general", but a target of that name already exists.
It's generally a bad idea to have in our source tree multiple files with the
same name. Rename the test.
Fixes: 16cd84d346 ('build/meson: rename platform tests to use same name as autotools'):
