Commit graph

16 commits

Author SHA1 Message Date
Thomas Haller
c9bbd15597
build/meson: explicitly link libnm-core-aux-intern 2021-02-28 10:42:05 +01:00
Thomas Haller
e2004d2849
build/meson: cleanup dependencies for libnm-core-impl 2021-02-28 10:42:05 +01:00
Thomas Haller
e560b551ae
build/meson: remove unnecessary libnm_core_intern_dep 2021-02-28 10:42:05 +01:00
Thomas Haller
bb4a10719c
build/meson: cleanup dependencies for libnm-platform 2021-02-28 10:42:04 +01:00
Thomas Haller
cac8e895b6
build/meson: cleanup dependencies for libnm-udev-aux 2021-02-28 10:42:04 +01:00
Thomas Haller
fd69080c9b
build/meson: cleanup dependencies for libnm-systemd-shared 2021-02-28 10:42:04 +01:00
Thomas Haller
a9540fb927
build/meson: drop libnm_log_core_dep dependency 2021-02-28 10:42:04 +01:00
Thomas Haller
309dccf5f9
build/meson: cleanup libnm-glib-aux dependencies
Avoid dependencies but explicitly link the static library where it is
used.

This also fixes that we linked libnm-log-core into
libnm-settings-plugin-ifcfg-rh.so, which duplicated the symbols
while it should used them from NetworkManager.
2021-02-28 10:42:04 +01:00
Thomas Haller
bdabc9e38c
build/meson: cleanup build for c-util and nettools helper libraries
We have a number of static helper libraries. When a user is using such a
library, they need to set the include search paths (-I) and link with
the static library at the right place.

The first part, the include search path, is now trivial. We no longer
add the individual search paths but everybody uses "-I. -Isrc/".

The second part means that when we build a shared library or an
executable that uses symbols from the static library, we need to link
it. But only then, and not earlier so that not multiple intermediate
build products (static libraries too) contain the same code. Note that
for libnm-device-plugin-*.so and other core plugins it's even that
those shared modules should not themselves link with the static
helpers. Instead, the need to use the symbols from NetworkManager.

Easy enough. Previously, we would sometimes define dependencies in
meson. But as it's really simple, I think that those dependencies
obfuscate more than help. Instead drop them, and only explicitly link
where we need it. The exception is libNetworkManagerTest_dep, which
is still a dependency. Maybe that dependency is fine, as it is much
later in the process. Or maybe that will also be replaced in the future.
2021-02-28 10:41:24 +01:00
Thomas Haller
635d84b896
build: remove "shared/" from include search path
There is nothing left there.
2021-02-24 12:49:06 +01:00
Thomas Haller
9dc84b32b0
build: move "shared/nm-{glib-aux,log-null,log-core}" to "src/libnm-{glib-aux,log-null,log-core}" 2021-02-24 12:48:20 +01:00
Thomas Haller
341b6e0704
all: change G_LOG_DOMAIN to "nm"
glib requires G_LOG_DOMAIN defined so that log messages are labeled
to belong to NetworkManager or libnm.

However, we don't actually want to use glib logging. Our library libnm
MUST not log anything, because it spams the user's stdout/stderr.
Instead, a library must report notable events via its API. Note that
there is also LIBNM_CLIENT_DEBUG to explicitly enable debug logging,
but that doesn't use glib logging either.

Also, the daemon does not use glib logging instead it logs to syslog.
When run with `--debug`.

Hence, it's not useful for us to define different G_LOG_DOMAIN per
library/application, because none of our libraries/applications should
use glib logging.

It also gets slightly confusing, because we have the static library like
`src/libnm-core-impl`, which is both linked into `libnm` (the library)
and `NetworkManager` (the daemon). Which logging domain should they use?

Set the G_LOG_DOMAIN to "nm" everywhere. But no longer do it via `-D`
arguments to the compiler.

See-also: https://developer.gnome.org/glib/stable/glib-Message-Logging.html#G-LOG-DOMAIN:CAPS
2021-02-18 19:46:57 +01:00
Thomas Haller
fdf9614ba7
build: move "libnm-core/" to "src/" and split it
"libnm-core/" is rather complicated. It provides a static library that
is linked into libnm.so and NetworkManager. It also contains public
headers (like "nm-setting.h") which are part of public libnm API.

Then we have helper libraries ("libnm-core/nm-libnm-core-*/") which
only rely on public API of libnm-core, but are themself static
libraries that can be used by anybody who uses libnm-core. And
"libnm-core/nm-libnm-core-intern" is used by libnm-core itself.

Move "libnm-core/" to "src/". But also split it in different
directories so that they have a clearer purpose.

The goal is to have a flat directory hierarchy. The "src/libnm-core*/"
directories correspond to the different modules (static libraries and set
of headers that we have). We have different kinds of such modules because
of how we combine various code together. The directory layout now reflects
this.
2021-02-18 19:46:51 +01:00
Thomas Haller
c971ee2267
libnm: merge libnm-keyfile into libnm-core
Before there was a licensing conflict between the keyfile code
(libnm-keyfile) and libnm. The latter would require LGPL-2.1+ while
keyfile code was GPL-2.0+.

Consequently we were linking libnm-keyfile into the daemon, but not in
libnm.so.

This conflict has been resolved and keyfile API is part of libnm.so.
There is no more need to build a separate (intermediary) library. Merge
them.

This also makes sense because keyfile code needs access to private code
from libnm-core. It is closely tied to libnm-core, so that building them
separate makes no sense (anymore).
2021-02-09 12:38:19 +01:00
Thomas Haller
dc2afc9b77
all: add "src/core/nm-default-daemon.h" as replacement for "nm-default.h" 2021-02-09 12:38:18 +01:00
Thomas Haller
ac1a9e03e4
all: move "src/" directory to "src/core/"
Currently "src/" mostly contains the source code of the daemon.
I say mostly, because that is not true, there are also the device,
settings, wwan, ppp plugins, the initrd generator, the pppd and dhcp
helper, and probably more.

Also we have source code under libnm-core/, libnm/, clients/, and
shared/ directories. That is all confusing.

We should have one "src" directory, that contains subdirectories. Those
subdirectories should contain individual parts (libraries or
applications), that possibly have dependencies on other subdirectories.
There should be a flat hierarchy of directories under src/, which
contains individual modules.

As the name "src/" is already taken, that prevents any sensible
restructuring of the code.

As a first step, move "src/" to "src/core/". This gives space to
reorganize the code better by moving individual components into "src/".

For inspiration, look at systemd's "src/" directory.

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/743
2021-02-04 09:45:55 +01:00
Renamed from src/meson.build (Browse further)