Commit Graph

4 Commits

Author SHA1 Message Date
Thomas Haller
22ef6a507a build: refine the NETWORKMANAGER_COMPILATION define
Note that:

 - we compile some source files multiple times. Most notably those
   under "shared/".

 - we include a default header "shared/nm-default.h" in every source
   file. This header is supposed to setup a common environment by defining
   and including parts that are commonly used. As we always include the
   same header, the header must behave differently depending
   one whether the compilation is for libnm-core, NetworkManager or
   libnm-glib. E.g. it must include <glib/gi18n.h> or <glib/gi18n-lib.h>
   depending on whether we compile a library or an application.

For that, the source files need the NETWORKMANAGER_COMPILATION #define
to behave accordingly.

Extend the define to be composed of flags. These flags are all named
NM_NETWORKMANAGER_COMPILATION_WITH_*, they indicate which part of the
build are available. E.g. when building libnm-core.la itself, then
WITH_LIBNM_CORE, WITH_LIBNM_CORE_INTERNAL, and WITH_LIBNM_CORE_PRIVATE
are available. When building NetworkManager, WITH_LIBNM_CORE_PRIVATE
is not available but the internal parts are still accessible. When
building nmcli, only WITH_LIBNM_CORE (the public part) is available.
This granularily controls the build.
2018-01-08 12:38:53 +01:00
Thomas Haller
4199c976da libnm: fix normalizing and verifying OVS connections
Normalizing can be complicated, as settings depend on each other and possibly
conflict.

That is, because verify() must exactly anticipate whether normalization will
succeed and how the result will look like. That is because we only want to
modify the connection, if we are sure that the result will verify.

Hence, verify() and normalize() are strongly related. The implementation
should not be spread out between NMSettingOvsInterface:verify(),
NMSettingOvsPatch:verify() and _normalize_ovs_interface_type().

Also, add some unit-tests.
2017-10-30 21:46:55 +01:00
Lubomir Rintel
9b28c9ba91 core: infer the bluetooth type from the presence of the supplemental settings
When the user sets a GSM or CDMA setting along with a Bluetooth setting
we know we're dealing with a DUN profile. No need to ask.

[thaller@redhat.com: verify() and normalize() must strongly agree whether a
connection is normalizable, and now to do it. That is, after verify()
determines the connection is normalizable, normalize() must fix it as
anticipated.

The reason is, we only want to modify the connection, if we are able
to create a valid result. Hence, after normalize() it *must* verify().

Try to simplify that by moving the logic of fixing the bt-type to a
common place _nm_connection_detect_bluetooth_type().]

Co-Authored-By: Thomas Haller <thaller@redhat.com>
2017-08-23 16:18:44 +02:00
Dan Winship
9e5c7d915b libnm-core: make nm_setting_verify() take an NMConnection
nm_setting_verify() took a GSList of other NMSettings, but really it
would just be simpler all around to pass the NMConnection instead...

This means that several formerly NMSetting-branded functions that
operated on lists-of-settings now get replaced with
NMConnection-branded functions instead.
2014-10-28 17:17:17 -04:00