From the files under "shared/nm-utils" we build an internal library
that provides glib-based helper utilities.

Move the files of that basic library to a new subdirectory
"shared/nm-glib-aux" and rename the helper library "libnm-core-base.la"
to "libnm-glib-aux.la".

Reasons:

 - the name "utils" is overused in our code-base. Everything's an
   "utils". Give this thing a more distinct name.

 - there were additional files under "shared/nm-utils", which are not
   part of this internal library "libnm-utils-base.la". All the files
   that are part of this library should be together in the same
   directory, but files that are not, should not be there.

 - the new name should better convey what this library is and what is isn't:
   it's a set of utilities and helper functions that extend glib with
   funcitonality that we commonly need.

There are still some files left under "shared/nm-utils". They have less
a unifying propose to be in their own directory, so I leave them there
for now. But at least they are separate from "shared/nm-glib-aux",
which has a very clear purpose.

(cherry picked from commit 80db06f7)

We need this for a little little longer :(

This reverts commit 1de8383a.

This removes libnm-glib, libnm-glib-vpn, and libnm-util for good.
The it has been replaced with libnm since NetworkManager 1.0, disabled
by default since 1.12 and no up-to-date distributions ship it for years
now.

Removing the libraries allows us to:

* Remove the horrible hacks that were in place to deal with accidental use
  of both the new and old library in a single process.
* Relief the translators of maintenance burden of similar yet different
  strings.
* Get rid of known bad code without chances of ever getting fixed
  (libnm-glib/nm-object.c and libnm-glib/nm-object-cache.c)
* Generally lower the footprint of the releases and our workspace

If there are some really really legacy users; they can just build
libnm-glib and friends from the NetworkManager-1.16 distribution. The
D-Bus API is stable and old libnm-glib will keep working forever.

https://github.com/NetworkManager/NetworkManager/pull/308

Various annotations were added using multiple colons, while only one has
to be added or g-ir-introspect will consider them part of the description

!94
(cherry picked from commit 73005fcf)

Various annotations were added using multiple colons, while only one has
to be added or g-ir-introspect will consider them part of the description

!94

"nm-macros-interal.h" already includes <errno.h> and <string.h>.
No need to include it everywhere else too.

For static functions inside a module, the compiler determines on its own
whether to inline the function.

Also, "inline" was used at some places that don't immediatly look like
candidates for inlining. It was most likely a copy&paste error.

Like also done for autotools, create and use intermediate libraries
from "shared/nm-utils/".

Also, replace "shared_dep" by "shared_nm_utils_base_dep". We don't
need super fine-grained selection of what we link. We can always
link in "shared/libnm-utils-base.a", and let the linker throw away
unsed parts.

Add missing trailing commas that avoids getting noise when another
file/parameter is added and eases reviewing changes[0].

[0] https://gitlab.gnome.org/GNOME/dconf/merge_requests/11#note_291585

Correct the spelling across the *entire* tree, including translations,
comments, etc. It's easier that way.

Even the places where it's not exposed to the user, such as tests, so
that we learn how is it spelled correctly.

Remainder of typos found using `codespell -q 3 --skip="./shared,./src/systemd,*.po" -I ../NetworkManager-word-whitelist.txt` whereby whitelist consists of:
 ```
ans
busses
cace
cna
conexant
crasher
iff
liftime
creat
nd
sav
technik
uint
```

https://github.com/NetworkManager/NetworkManager/pull/205

This was broken by e01f7f2c.
Port the commit's changes from libnm to libnm-util.

(cherry picked from commit 4bfd0bab)

This was broken by e01f7f2c.
Port the commit's changes from libnm to libnm-util.

At other places, we already use __BYTE_ORDER define to detect endianness.
We don't need multiple mechanisms.

Also note that meson did not do the correct thing as AC_C_BIGENDIAN,
so meson + nss + big-endian was possibly broken.

https://github.com/NetworkManager/NetworkManager/pull/189

- Don't use @parent_class name. This local variable (and @object_class) is
  the class instance up-cast to the pointer types of the parents. The point
  here is not that it is the direct parent. The point is, that it's the
  NMSettingClass type.
  Also, it can only be used inconsistently, in face of NMSettingIP4Config,
  who's parent type is NMSettingIPConfig. Clearly, inside
  nm-setting-ip4-config.c we wouldn't want to use the "parent_class"
  name. Consistently rename @parent_class to @setting_class.

- Also rename the pointer to the own class to @klass. "setting_class" is also the
  wrong name for that, because the right name would be something like
  "setting_6lowpan_class".
  However, "klass" is preferred over the latter, because we commonly create new
  GObject implementations by copying an existing one. Generic names like "klass"
  and "self" inside a type implementation make that simpler.

- drop useless comments like

     /* virtual functions */
     /* Properties */

  It's better to logically and visually structure the code, and avoid trival
  remarks about that. They only end up being used inconsistently. If you
  even need a stronger visual separator, then an 80 char /****/ line
  should be preferred.

1) the command line gets shorter. I frequently run `make V=1` to see
   the command line arguments for the compiler, and there is a lot
   of noise.

2) define each of these variables at one place. This makes it easy
   to verify that for all compilation units, a particular
   define has the same value. Previously that was not obvious or
   even not the case (see commit e5d1a713
   and commit d63cf1ef).
   The point is to avoid redundancy.

3) not all compilation units need all defines. In fact, most modules
   would only need a few of these defines. We aimed to pass the necessary
   minium of defines to each compilation unit, but that was non-obvious
   to get right and often we set a define that wasn't used. See for example
   "src_settings_plugins_ibft_cppflags" which needlessly had "-DSYSCONFDIR".
   This question is now entirely avoided by just defining all variables in
   a header. We don't care to find the minimum, because every component
   gets anyway all defines from the header.

4) this also avoids the situation, where a module that previously did
   not use a particular define gets modified to require it. Previously,
   that would have required to identify the missing define, and add
   it to the CFLAGS of the complation unit. Since every compilation
   now includes "config-extra.h", all defines are available everywhere.

5) the fact that each define is now available in all compilation units
   could be perceived as a downside. But it isn't, because these defines
   should have a unique name and one specific value. Defining the same
   name with different values, or refer to the same value by different
   names is a bug, not a desirable feature. Since these defines should
   be unique accross the entire tree, there is no problem in providing
   them to every compilation unit.

6) the reason why we generate "config-extra.h" this way, instead of using
   AC_DEFINE() in configure.ac, is due to the particular handling of
   autoconf for directory variables. See [1].
   With meson, it would be trivial to put them into "config.h.meson".
   While that is not easy with autoconf, the "config-extra.h" workaround
   seems still preferable to me.

[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Installation-Directory-Variables.html

We commonly don't use the glib typedefs for char/short/int/long,
but their C types directly.

    $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
    587
    $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
    21114

One could argue that using the glib typedefs is preferable in
public API (of our glib based libnm library) or where it clearly
is related to glib, like during

  g_object_set (obj, PROPERTY, (gint) value, NULL);

However, that argument does not seem strong, because in practice we don't
follow that argument today, and seldomly use the glib typedefs.
Also, the style guide for this would be hard to formalize, because
"using them where clearly related to a glib" is a very loose suggestion.

Also note that glib typedefs will always just be typedefs of the
underlying C types. There is no danger of glib changing the meaning
of these typedefs (because that would be a major API break of glib).

A simple style guide is instead: don't use these typedefs.

No manual actions, I only ran the bash script:

  FILES=($(git ls-files '*.[hc]'))
  sed -i \
      -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
      -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>  /\1   /g' \
      -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
      "${FILES[@]}"

Targets not depended on by anything are not useful and likely never get run.

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.

Use two common defines NM_BUILD_SRCDIR and NM_BUILD_BUILDDIR
for specifying the location of srcdir and builddir.

Note that this is only relevant for tests, as they expect
a certain layout of the directories, to find files that concern
them.

  libnm-util/crypto_gnutls.c: In function crypto_encrypt:
  libnm-util/crypto_gnutls.c:245:8: error: variable salt_len set but not used [-Werror=unused-but-set-variable]
    gsize salt_len;
          ^~~~~~~~

See-also: 312c72f7

Coccinelle:

  @@
  expression a, b;
  @@
  -a ? a : b
  +a ?: b

Applied with:

  spatch --sp-file ternary.cocci --in-place --smpl-spacing --dir .

With some manual adjustments on spots that Cocci didn't catch for
reasons unknown.

Thanks to the marvelous effort of the GNU compiler developer we can now
spare a couple of bits that could be used for more important things,
like this commit message. Standards commitees yet have to catch up.

Normalize coding style by removing consecutive empty lines from C
sources and headers.

https://github.com/NetworkManager/NetworkManager/pull/108

There are multiple tests with the same in different directories; add a
unique prefix to test names so that it is clear from the output which
one is running.

Like autotools, use the wrapper script 'run-nm-test.sh' that starts a
separate D-Bus session when needed.

The code was passing the gpointer alias of the GValue, rather than the
GValue* itself. This doesn’t matter normally, but broke an experimental
patch in GLib to remove a cast from G_VALUE_TYPE.

We’ve reverted the patch in GLib (see
https://bugzilla.gnome.org/show_bug.cgi?id=793186), but this should be
fixed in NetworkManager anyway.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

https://bugzilla.gnome.org/show_bug.cgi?id=793302

We commonly only allow tabs at the beginning of a line, not
afterwards. The reason for this style is so that the code
looks formated right with tabstop=4 and tabstop=8.

NM_API_VERSION is a better name. It's not the current stable
version, but the version number of the API which the current
NM_VERSION provides. In practice, NM_API_VERSION is either identical
to NM_VERSION (in case of a release) or NM_VERSION is a development
version leading up the the upcoming NM_API_VERSION.

For example, with the new name the check

  #if NM_VERSION != NM_API_VERSION
  # warning this is an development version
  #endif

makes more sense.

We don't need to have two version defines "CUR" and "NEXT".

The main purpose of these macros (if not their only), is to
make NM_AVAILABLE_IN_* and NM_DEPRECATED_IN_* macros work.

1) At the precise commit of a release, "CUR" and "NEXT" must be identical,
because whenever the user configures NM_VERSION_MIN_REQUIRED and
NM_VERSION_MAX_ALLOWED, then they both compare against the current
version, at which point "CUR" == "NEXT".

2) Every other commit aside the release, is a development version that leads
up the the next coming release. But as far as versioning is concerned, such
a development version should be treated like that future release. It's unstable
API and it may or may not be close to later API of the release. But
we shall treat it as that version. Hence, also in this case, we want to
set both "NM_VERSION_CUR_STABLE" and again NEXT to the future version.

This makes NM_VERSION_NEXT_STABLE redundant.

Previously, the separation between current and next version would for
example allow that NM_VERSION_CUR_STABLE is the previously release
stable API, and NM_VERSION_NEXT_STABLE is the version of the next upcoming
stable API. So, we could allow "examples" to make use of development
API, but other(?) internal code still restrict to unstable API. But it's
unclear which other code would want to avoid current development.

Also, the points 1) and 2) were badly understood. Note that for our
previousy releases, we usually didn't bump the macros at the stable
release (and if we did, we didn't set them to be the same). While using
two macros might be more powerful, it is hard to grok and easy to
forget to bump the macros a the right time. One macro shall suffice.

All this also means, that *immediately* after making a new release, we shall
bump the version number in `configure.ac` and "NM_VERSION_CUR_STABLE".

RHEL 7.1 and Ubuntu 14.04 LTS both have this.

https://bugzilla.gnome.org/show_bug.cgi?id=792323

We also unconditionally use them with autotools.
Also, the detection for have_version_script does
not seem correct to me. At least, it didn't work
with clang.

The strings holding the names used for libraries have also been
moved to different variables. This way they would be less error
as these variables can be reused easily and any typing error
would be quickly detected.

Some targets are missing dependencies on some generated sources in
the meson port. These makes the build to fail due to missing source
files on a highly parallelized build.

These dependencies have been resolved by taking advantage of meson's
internal dependencies which can be used to pass source files,
include directories, libraries and compiler flags.

One of such internal dependencies called `core_dep` was already in
use. However, in order to avoid any confusion with another new
internal dependency called `nm_core_dep`, which is used to include
directories and source files from the `libnm-core` directory, the
`core_dep` dependency has been renamed to `nm_dep`.

These changes have allowed minimizing the build details which are
inherited by using those dependencies. The parallelized build has
also been improved.

These files are a template how to add a new nm-setting-* implementation.

We are not going to add new files to the deprecated libnm-util library,
hence a template for libnm-util is pointless.

libnm-core doesn't have a corresponding template file. Personally, I
don't think such a template are a great idea either, because

  - People are not aware that it exists. Hence, it's unused, badly
    maintained and quite possibly does not follow current best practice.
  - Just copy an actual settings implementation and start from there.
    That seems better to me than having a template.

Tests are commonly created via copy&paste. Hence, it's
better to express a certain concept explicitly via a function
or macro. This way, the implementation of the concept can be
adjusted at one place, without requiring to change all the callers.

Also, the macro is shorter, and brevity is better for tests
so it's easier to understand what the test does. Without being
bothered by noise from the redundant information.

Also, the macro knows better which message to expect. For example,
messages inside "src" are prepended by nm-logging.c with a level
and a timestamp. The expect macro is aware of that and tests for it

  #define NMTST_EXPECT_NM_ERROR(msg)      NMTST_EXPECT_NM (G_LOG_LEVEL_MESSAGE, "*<error> [*] "msg)

This again allows the caller to ignore this prefix, but still assert
more strictly.

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.