2017-11-25 11:39:06 +01:00
|
|
|
libnm_core_inc = include_directories('.')
|
|
|
|
|
|
2019-09-07 23:00:41 +02:00
|
|
|
libnm_core_nm_default_dep = declare_dependency(
|
|
|
|
|
sources: nm_version_macro_header,
|
|
|
|
|
include_directories: libnm_core_inc,
|
|
|
|
|
dependencies: glib_nm_default_dep,
|
|
|
|
|
)
|
|
|
|
|
|
2017-11-25 11:39:06 +01:00
|
|
|
libnm_core_headers = files(
|
|
|
|
|
'nm-connection.h',
|
|
|
|
|
'nm-core-types.h',
|
|
|
|
|
'nm-dbus-interface.h',
|
|
|
|
|
'nm-errors.h',
|
2018-05-22 15:41:29 +02:00
|
|
|
'nm-setting-6lowpan.h',
|
2017-11-25 11:39:06 +01:00
|
|
|
'nm-setting-8021x.h',
|
|
|
|
|
'nm-setting-adsl.h',
|
|
|
|
|
'nm-setting-bluetooth.h',
|
|
|
|
|
'nm-setting-bond.h',
|
|
|
|
|
'nm-setting-bridge-port.h',
|
|
|
|
|
'nm-setting-bridge.h',
|
|
|
|
|
'nm-setting-cdma.h',
|
|
|
|
|
'nm-setting-connection.h',
|
|
|
|
|
'nm-setting-dcb.h',
|
|
|
|
|
'nm-setting-dummy.h',
|
2018-09-11 14:42:21 +02:00
|
|
|
'nm-setting-ethtool.h',
|
2017-11-25 11:39:06 +01:00
|
|
|
'nm-setting-generic.h',
|
|
|
|
|
'nm-setting-gsm.h',
|
|
|
|
|
'nm-setting-infiniband.h',
|
|
|
|
|
'nm-setting-ip-config.h',
|
|
|
|
|
'nm-setting-ip-tunnel.h',
|
|
|
|
|
'nm-setting-ip4-config.h',
|
|
|
|
|
'nm-setting-ip6-config.h',
|
|
|
|
|
'nm-setting-macsec.h',
|
|
|
|
|
'nm-setting-macvlan.h',
|
2018-08-07 15:52:56 +02:00
|
|
|
'nm-setting-match.h',
|
2017-11-25 11:39:06 +01:00
|
|
|
'nm-setting-olpc-mesh.h',
|
|
|
|
|
'nm-setting-ovs-bridge.h',
|
|
|
|
|
'nm-setting-ovs-interface.h',
|
2019-06-11 15:53:05 +02:00
|
|
|
'nm-setting-ovs-dpdk.h',
|
2017-11-25 11:39:06 +01:00
|
|
|
'nm-setting-ovs-patch.h',
|
|
|
|
|
'nm-setting-ovs-port.h',
|
|
|
|
|
'nm-setting-ppp.h',
|
|
|
|
|
'nm-setting-pppoe.h',
|
|
|
|
|
'nm-setting-proxy.h',
|
|
|
|
|
'nm-setting-serial.h',
|
2018-05-25 12:05:24 +02:00
|
|
|
'nm-setting-sriov.h',
|
2017-11-25 11:39:06 +01:00
|
|
|
'nm-setting-tc-config.h',
|
|
|
|
|
'nm-setting-team-port.h',
|
|
|
|
|
'nm-setting-team.h',
|
|
|
|
|
'nm-setting-tun.h',
|
|
|
|
|
'nm-setting-user.h',
|
|
|
|
|
'nm-setting-vlan.h',
|
|
|
|
|
'nm-setting-vpn.h',
|
|
|
|
|
'nm-setting-vxlan.h',
|
2019-01-28 12:39:38 +01:00
|
|
|
'nm-setting-wifi-p2p.h',
|
2017-11-25 11:39:06 +01:00
|
|
|
'nm-setting-wimax.h',
|
|
|
|
|
'nm-setting-wired.h',
|
2018-12-27 16:48:30 +01:00
|
|
|
'nm-setting-wireguard.h',
|
2017-11-25 11:39:06 +01:00
|
|
|
'nm-setting-wireless-security.h',
|
|
|
|
|
'nm-setting-wireless.h',
|
2018-03-09 10:51:49 +01:00
|
|
|
'nm-setting-wpan.h',
|
2017-11-25 11:39:06 +01:00
|
|
|
'nm-setting.h',
|
|
|
|
|
'nm-simple-connection.h',
|
|
|
|
|
'nm-utils.h',
|
|
|
|
|
'nm-version.h',
|
|
|
|
|
'nm-vpn-dbus-interface.h',
|
|
|
|
|
'nm-vpn-editor-plugin.h',
|
2018-10-18 12:50:20 +02:00
|
|
|
'nm-vpn-plugin-info.h',
|
2017-11-25 11:39:06 +01:00
|
|
|
)
|
|
|
|
|
|
2017-12-15 14:35:31 +01:00
|
|
|
libnm_core_settings_sources = files(
|
2018-05-22 15:41:29 +02:00
|
|
|
'nm-setting-6lowpan.c',
|
2017-11-25 11:39:06 +01:00
|
|
|
'nm-setting-8021x.c',
|
|
|
|
|
'nm-setting-adsl.c',
|
|
|
|
|
'nm-setting-bluetooth.c',
|
|
|
|
|
'nm-setting-bond.c',
|
|
|
|
|
'nm-setting-bridge-port.c',
|
|
|
|
|
'nm-setting-bridge.c',
|
|
|
|
|
'nm-setting-cdma.c',
|
|
|
|
|
'nm-setting-connection.c',
|
|
|
|
|
'nm-setting-dcb.c',
|
|
|
|
|
'nm-setting-dummy.c',
|
libnm, cli, ifcfg-rh: add NMSettingEthtool setting
Note that in NetworkManager API (D-Bus, libnm, and nmcli),
the features are called "feature-xyz". The "feature-" prefix
is used, because NMSettingEthtool possibly will gain support
for options that are not only -K|--offload|--features, for
example -C|--coalesce.
The "xzy" suffix is either how ethtool utility calls the feature
("tso", "rx"). Or, if ethtool utility specifies no alias for that
feature, it's the name from kernel's ETH_SS_FEATURES ("tx-tcp6-segmentation").
If possible, we prefer ethtool utility's naming.
Also note, how the features "feature-sg", "feature-tso", and
"feature-tx" actually refer to multiple underlying kernel features
at once. This too follows what ethtool utility does.
The functionality is not yet implemented server-side.
2018-07-16 23:37:55 +02:00
|
|
|
'nm-setting-ethtool.c',
|
2017-11-25 11:39:06 +01:00
|
|
|
'nm-setting-generic.c',
|
|
|
|
|
'nm-setting-gsm.c',
|
|
|
|
|
'nm-setting-infiniband.c',
|
|
|
|
|
'nm-setting-ip-config.c',
|
|
|
|
|
'nm-setting-ip-tunnel.c',
|
|
|
|
|
'nm-setting-ip4-config.c',
|
|
|
|
|
'nm-setting-ip6-config.c',
|
|
|
|
|
'nm-setting-macsec.c',
|
|
|
|
|
'nm-setting-macvlan.c',
|
2018-08-07 15:52:56 +02:00
|
|
|
'nm-setting-match.c',
|
2017-11-25 11:39:06 +01:00
|
|
|
'nm-setting-olpc-mesh.c',
|
|
|
|
|
'nm-setting-ovs-bridge.c',
|
|
|
|
|
'nm-setting-ovs-interface.c',
|
2019-06-11 15:53:05 +02:00
|
|
|
'nm-setting-ovs-dpdk.c',
|
2017-11-25 11:39:06 +01:00
|
|
|
'nm-setting-ovs-patch.c',
|
|
|
|
|
'nm-setting-ovs-port.c',
|
|
|
|
|
'nm-setting-ppp.c',
|
|
|
|
|
'nm-setting-pppoe.c',
|
|
|
|
|
'nm-setting-proxy.c',
|
|
|
|
|
'nm-setting-serial.c',
|
2018-05-25 12:05:24 +02:00
|
|
|
'nm-setting-sriov.c',
|
2017-11-25 11:39:06 +01:00
|
|
|
'nm-setting-tc-config.c',
|
|
|
|
|
'nm-setting-team-port.c',
|
|
|
|
|
'nm-setting-team.c',
|
|
|
|
|
'nm-setting-tun.c',
|
|
|
|
|
'nm-setting-user.c',
|
|
|
|
|
'nm-setting-vlan.c',
|
|
|
|
|
'nm-setting-vpn.c',
|
|
|
|
|
'nm-setting-vxlan.c',
|
2019-01-28 12:39:38 +01:00
|
|
|
'nm-setting-wifi-p2p.c',
|
2017-11-25 11:39:06 +01:00
|
|
|
'nm-setting-wimax.c',
|
|
|
|
|
'nm-setting-wired.c',
|
2018-12-27 16:48:30 +01:00
|
|
|
'nm-setting-wireguard.c',
|
2017-11-25 11:39:06 +01:00
|
|
|
'nm-setting-wireless-security.c',
|
2018-03-09 10:51:49 +01:00
|
|
|
'nm-setting-wireless.c',
|
2018-10-18 12:50:20 +02:00
|
|
|
'nm-setting-wpan.c',
|
2017-12-15 14:35:31 +01:00
|
|
|
)
|
|
|
|
|
|
|
|
|
|
libnm_core_sources = libnm_core_settings_sources + files(
|
|
|
|
|
'nm-connection.c',
|
2019-05-06 12:11:23 +02:00
|
|
|
'nm-crypto.c',
|
2017-12-15 14:35:31 +01:00
|
|
|
'nm-dbus-utils.c',
|
|
|
|
|
'nm-errors.c',
|
|
|
|
|
'nm-keyfile-utils.c',
|
2019-05-06 12:11:23 +02:00
|
|
|
'nm-keyfile.c',
|
2017-12-15 14:35:31 +01:00
|
|
|
'nm-property-compare.c',
|
2017-11-25 11:39:06 +01:00
|
|
|
'nm-setting.c',
|
|
|
|
|
'nm-simple-connection.c',
|
2019-05-06 12:11:23 +02:00
|
|
|
'nm-team-utils.c',
|
2017-11-25 11:39:06 +01:00
|
|
|
'nm-utils.c',
|
|
|
|
|
'nm-vpn-editor-plugin.c',
|
2018-10-18 12:50:20 +02:00
|
|
|
'nm-vpn-plugin-info.c',
|
2017-11-25 11:39:06 +01:00
|
|
|
)
|
|
|
|
|
|
2019-09-03 09:48:59 +02:00
|
|
|
enum_headers = libnm_core_headers + [nm_version_macro_header]
|
2017-12-16 14:59:37 +01:00
|
|
|
enum_types = 'nm-core-enum-types'
|
2017-11-25 11:39:06 +01:00
|
|
|
|
2017-12-16 14:59:37 +01:00
|
|
|
libnm_core_enum = gnome.mkenums(
|
|
|
|
|
enum_types,
|
|
|
|
|
sources: enum_headers,
|
2017-11-25 11:39:06 +01:00
|
|
|
identifier_prefix: nm_id_prefix,
|
2017-12-16 14:59:37 +01:00
|
|
|
c_template: enum_types + '.c.template',
|
|
|
|
|
h_template: enum_types + '.h.template',
|
2017-11-25 11:39:06 +01:00
|
|
|
install_header: true,
|
2018-10-18 12:50:20 +02:00
|
|
|
install_dir: libnm_pkgincludedir,
|
2017-11-25 11:39:06 +01:00
|
|
|
)
|
|
|
|
|
|
shared: build helper "libnm-libnm-core-{intern|aux}.la" library for libnm-core
"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)
2019-04-15 09:26:53 +02:00
|
|
|
libnm_core_enum_dep = declare_dependency(
|
|
|
|
|
sources: libnm_core_enum[1],
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
###############################################################################
|
|
|
|
|
|
|
|
|
|
shared_nm_libnm_core_intern = static_library(
|
|
|
|
|
'nm-libnm-core-intern',
|
|
|
|
|
sources: files('../shared/nm-libnm-core-intern/nm-ethtool-utils.c',
|
|
|
|
|
'../shared/nm-libnm-core-intern/nm-libnm-core-utils.c'),
|
|
|
|
|
c_args: [
|
|
|
|
|
'-DG_LOG_DOMAIN="@0@"'.format(libnm_name),
|
|
|
|
|
'-DNETWORKMANAGER_COMPILATION=NM_NETWORKMANAGER_COMPILATION_LIBNM_CORE',
|
|
|
|
|
],
|
2019-09-03 09:48:59 +02:00
|
|
|
include_directories: libnm_core_inc,
|
shared: build helper "libnm-libnm-core-{intern|aux}.la" library for libnm-core
"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)
2019-04-15 09:26:53 +02:00
|
|
|
dependencies: [
|
|
|
|
|
libnm_core_enum_dep,
|
2019-09-07 23:00:41 +02:00
|
|
|
libnm_core_nm_default_dep,
|
shared: build helper "libnm-libnm-core-{intern|aux}.la" library for libnm-core
"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)
2019-04-15 09:26:53 +02:00
|
|
|
],
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
shared_nm_libnm_core_intern_dep = declare_dependency(
|
2019-09-03 09:48:59 +02:00
|
|
|
dependencies: libnm_systemd_shared_dep,
|
shared: build helper "libnm-libnm-core-{intern|aux}.la" library for libnm-core
"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)
2019-04-15 09:26:53 +02:00
|
|
|
link_with: shared_nm_libnm_core_intern,
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
###############################################################################
|
|
|
|
|
|
2017-11-25 11:39:06 +01:00
|
|
|
deps = [
|
2019-09-05 09:11:07 +02:00
|
|
|
crypto_dep,
|
2019-09-03 09:48:59 +02:00
|
|
|
libnm_utils_base_dep,
|
2017-11-25 11:39:06 +01:00
|
|
|
]
|
|
|
|
|
|
|
|
|
|
cflags = [
|
2018-01-09 08:05:15 +01:00
|
|
|
'-DG_LOG_DOMAIN="@0@"'.format(libnm_name),
|
2018-01-02 13:37:06 +01:00
|
|
|
'-DNETWORKMANAGER_COMPILATION=NM_NETWORKMANAGER_COMPILATION_LIBNM_CORE',
|
2017-11-25 11:39:06 +01:00
|
|
|
]
|
|
|
|
|
|
2019-09-05 09:11:07 +02:00
|
|
|
libnm_crypto = static_library(
|
|
|
|
|
'nm-crypto',
|
|
|
|
|
sources: 'nm-crypto-@0@.c'.format(crypto),
|
|
|
|
|
dependencies: deps,
|
|
|
|
|
c_args: cflags,
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
deps = [
|
|
|
|
|
dl_dep,
|
|
|
|
|
libnm_utils_base_dep,
|
|
|
|
|
libudev_dep,
|
|
|
|
|
uuid_dep,
|
|
|
|
|
shared_nm_libnm_core_intern_dep,
|
|
|
|
|
]
|
|
|
|
|
|
2017-11-25 11:39:06 +01:00
|
|
|
if enable_json_validation
|
2018-01-09 06:20:18 +01:00
|
|
|
libnm_core_sources += files('nm-json.c')
|
2017-11-25 11:39:06 +01:00
|
|
|
deps += jansson_dep
|
|
|
|
|
endif
|
|
|
|
|
|
build/meson: fix meson build for shared files
The files in shared/nm-utils are not compiled as one static library,
instead each subproject that needs (parts of) them, re-compiles the
files individually.
The major reason for that is, because we might have different compile
flags, depending on whether we build libnm-core or
libnm-util/libnm-glib. Actually, I think that is not really the case,
and maybe this should be refactored, to indeed build them all as a
static library first.
Anyway, libnm-util, libnm-glib, clients' common lib, they all need a
different set of shared files that they should compile. Refactor
"shared/meson.build" to account for that and handle it like autotools
does.
Another change is, that "shared_c_siphash_dep" no longer advertises
"include_directories: include_directories('c-siphash/src')". We don't
put c-siphash.h into the include search path. Users who need it, should
include it via "#include <c-siphash/src/c-siphash.h>". The only exception
is when building shared_n_acd library, which is not under our control.
2018-05-30 15:16:01 +02:00
|
|
|
libnm_core_sources_all = libnm_core_sources
|
|
|
|
|
libnm_core_sources_all += libnm_core_enum
|
2019-09-03 09:48:59 +02:00
|
|
|
libnm_core_sources_all += nm_meta_setting_source
|
|
|
|
|
libnm_core_sources_all += [nm_version_macro_header]
|
build/meson: fix meson build for shared files
The files in shared/nm-utils are not compiled as one static library,
instead each subproject that needs (parts of) them, re-compiles the
files individually.
The major reason for that is, because we might have different compile
flags, depending on whether we build libnm-core or
libnm-util/libnm-glib. Actually, I think that is not really the case,
and maybe this should be refactored, to indeed build them all as a
static library first.
Anyway, libnm-util, libnm-glib, clients' common lib, they all need a
different set of shared files that they should compile. Refactor
"shared/meson.build" to account for that and handle it like autotools
does.
Another change is, that "shared_c_siphash_dep" no longer advertises
"include_directories: include_directories('c-siphash/src')". We don't
put c-siphash.h into the include search path. Users who need it, should
include it via "#include <c-siphash/src/c-siphash.h>". The only exception
is when building shared_n_acd library, which is not under our control.
2018-05-30 15:16:01 +02:00
|
|
|
|
2017-11-25 11:39:06 +01:00
|
|
|
libnm_core = static_library(
|
|
|
|
|
'nm-core',
|
build/meson: fix meson build for shared files
The files in shared/nm-utils are not compiled as one static library,
instead each subproject that needs (parts of) them, re-compiles the
files individually.
The major reason for that is, because we might have different compile
flags, depending on whether we build libnm-core or
libnm-util/libnm-glib. Actually, I think that is not really the case,
and maybe this should be refactored, to indeed build them all as a
static library first.
Anyway, libnm-util, libnm-glib, clients' common lib, they all need a
different set of shared files that they should compile. Refactor
"shared/meson.build" to account for that and handle it like autotools
does.
Another change is, that "shared_c_siphash_dep" no longer advertises
"include_directories: include_directories('c-siphash/src')". We don't
put c-siphash.h into the include search path. Users who need it, should
include it via "#include <c-siphash/src/c-siphash.h>". The only exception
is when building shared_n_acd library, which is not under our control.
2018-05-30 15:16:01 +02:00
|
|
|
sources: libnm_core_sources_all,
|
2017-11-25 11:39:06 +01:00
|
|
|
dependencies: deps,
|
2018-08-30 08:30:19 +02:00
|
|
|
link_with: libnm_crypto,
|
2018-10-18 12:50:20 +02:00
|
|
|
c_args: cflags,
|
2017-11-25 11:39:06 +01:00
|
|
|
)
|
|
|
|
|
|
2019-04-15 16:46:54 +02:00
|
|
|
libnm_core_dep = declare_dependency(
|
2018-01-07 15:39:42 +01:00
|
|
|
sources: libnm_core_enum[1],
|
|
|
|
|
include_directories: libnm_core_inc,
|
2018-05-30 13:19:07 +02:00
|
|
|
dependencies: [
|
2018-12-28 21:30:03 +01:00
|
|
|
libnm_systemd_shared_dep,
|
2019-09-03 09:48:59 +02:00
|
|
|
shared_nm_libnm_core_intern_dep,
|
2018-05-30 13:19:07 +02:00
|
|
|
],
|
2018-01-07 15:39:42 +01:00
|
|
|
)
|
|
|
|
|
|
shared: build helper "libnm-libnm-core-{intern|aux}.la" library for libnm-core
"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)
2019-04-15 09:26:53 +02:00
|
|
|
###############################################################################
|
|
|
|
|
|
|
|
|
|
shared_nm_libnm_core_aux = static_library(
|
|
|
|
|
'nm-libnm-core-aux',
|
2019-04-20 21:04:18 +02:00
|
|
|
sources: files('../shared/nm-libnm-core-aux/nm-libnm-core-aux.c'),
|
shared: build helper "libnm-libnm-core-{intern|aux}.la" library for libnm-core
"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)
2019-04-15 09:26:53 +02:00
|
|
|
c_args: [
|
|
|
|
|
'-DG_LOG_DOMAIN="@0@"'.format(libnm_name),
|
|
|
|
|
'-DNETWORKMANAGER_COMPILATION=(NM_NETWORKMANAGER_COMPILATION_WITH_GLIB|NM_NETWORKMANAGER_COMPILATION_WITH_GLIB_I18N_LIB)',
|
|
|
|
|
],
|
2019-09-03 09:48:59 +02:00
|
|
|
include_directories: libnm_core_inc,
|
shared: build helper "libnm-libnm-core-{intern|aux}.la" library for libnm-core
"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)
2019-04-15 09:26:53 +02:00
|
|
|
dependencies: [
|
2019-04-20 21:04:18 +02:00
|
|
|
libnm_core_dep,
|
2019-09-03 09:48:59 +02:00
|
|
|
libnm_utils_base_dep,
|
shared: build helper "libnm-libnm-core-{intern|aux}.la" library for libnm-core
"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)
2019-04-15 09:26:53 +02:00
|
|
|
],
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
shared_nm_libnm_core_aux_dep = declare_dependency(
|
|
|
|
|
link_with: shared_nm_libnm_core_aux,
|
|
|
|
|
dependencies: [
|
2019-04-15 16:46:54 +02:00
|
|
|
libnm_core_dep,
|
shared: build helper "libnm-libnm-core-{intern|aux}.la" library for libnm-core
"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)
2019-04-15 09:26:53 +02:00
|
|
|
libnm_systemd_shared_dep,
|
|
|
|
|
],
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
###############################################################################
|
|
|
|
|
|
2019-08-28 11:54:11 +02:00
|
|
|
enums_to_docbook = join_paths(source_root, 'tools', 'enums-to-docbook.pl')
|
2017-11-25 11:39:06 +01:00
|
|
|
|
|
|
|
|
docbooks = [
|
|
|
|
|
['nm-dbus-types', 'nm-dbus-interface.h', 'NetworkManager D-Bus API Types'],
|
2018-10-18 12:50:20 +02:00
|
|
|
['nm-vpn-dbus-types', 'nm-vpn-dbus-interface.h', 'VPN Plugin D-Bus API Types'],
|
2017-11-25 11:39:06 +01:00
|
|
|
]
|
|
|
|
|
|
|
|
|
|
foreach docbook: docbooks
|
|
|
|
|
output = docbook[0] + '.xml'
|
|
|
|
|
|
|
|
|
|
xml = custom_target(
|
|
|
|
|
output,
|
|
|
|
|
input: docbook[1],
|
|
|
|
|
output: output,
|
|
|
|
|
capture: true,
|
2017-12-24 14:52:02 +01:00
|
|
|
command: [perl, enums_to_docbook, docbook[0], docbook[2], '@INPUT@'],
|
|
|
|
|
# FIXME: gtkdoc does not depend directly on this.
|
|
|
|
|
# https://github.com/mesonbuild/meson/pull/2806
|
2018-10-18 12:50:20 +02:00
|
|
|
build_by_default: true,
|
2017-11-25 11:39:06 +01:00
|
|
|
)
|
|
|
|
|
|
|
|
|
|
content_files += xml.full_path()
|
|
|
|
|
endforeach
|
|
|
|
|
|
shared: build helper "libnm-libnm-core-{intern|aux}.la" library for libnm-core
"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)
2019-04-15 09:26:53 +02:00
|
|
|
###############################################################################
|
|
|
|
|
|
2017-11-25 11:39:06 +01:00
|
|
|
if enable_tests
|
|
|
|
|
subdir('tests')
|
|
|
|
|
endif
|