delta/NetworkManager.git/examples/C, branch lr/python3

all: use the elvis operator wherever possible

2018-05-10T12:36:58+00:00

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.

all: remove consecutive empty lines

2018-04-30T14:24:52+00:00

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

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

all: drop trailing spaces

2018-02-07T12:32:04+00:00

version: drop NM_VERSION_MAX_ALLOWED defines for internal build

2018-01-23T09:50:34+00:00

It already defaults to the right value. We only need to define
NM_VERSION_MIN_REQUIRED, so that parts of our internal build
can make use of deprecated API.

version: combine NM_VERSION_CUR_STABLE and NM_VERSION_NEXT_STABLE

2018-01-23T09:50:34+00:00

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".

all: require glib 2.40

2018-01-18T10:45:36+00:00

RHEL 7.1 and Ubuntu 14.04 LTS both have this.

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

meson: Improve dependency system

2018-01-10T11:20:17+00:00

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.

build: use template files for enum types' sources generation

2017-12-18T10:25:06+00:00

Source files for enum types are generated by passing segments of the
source code of the files to the `glib-mkenums` command.

This patch removes those parameters where source code is used from
meson build files by moving those segmeents to template files.

https://mail.gnome.org/archives/networkmanager-list/2017-December/msg00057.html

build: add initial support for meson build system

2017-12-13T14:48:50+00:00

meson is a build system focused on speed an ease of use, which
helps speeding up the software development. This patch adds meson
support along autotools.

[thaller@redhat.com: rebased patch and adjusted for iwd support]

https://mail.gnome.org/archives/networkmanager-list/2017-December/msg00022.html

examples: linker requires that library dependencies follow use

2017-09-21T11:14:56+00:00

On modern distributions, ld runs with the '--as-needed' option
enabled by default, meaning library dependencies must come after
files that require them. Also, this allows indirect linking so the
build commands can be simplified.

The alternative is to add the '-Wl,--no-as-needed' gcc option or
use the top-level Makefile.

Tested on:
 * Ubuntu 16.04.3 with gcc Ubuntu 5.4.1-8ubuntu1
 * Fedora 24 with gcc Red Hat 6.1.1-3

Signed-off-by: Lucas Magasweran 

https://mail.gnome.org/archives/networkmanager-list/2017-September/msg00022.html
https://mail.gnome.org/archives/networkmanager-list/2017-September/msg00023.html
https://mail.gnome.org/archives/networkmanager-list/2017-September/msg00025.html