If passed a relative path, load the editor .so from the same directory
as the plugin .so. This is useful for development, as it allows running
the editor plugin from the build tree conveniently.

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

(imported from NetworkManager commit 25f625b4fc58f56b7ab84dbcfc155bc210f3ee66)

I suppose NM_VPN_PLUGIN_ERROR is slightly less wrong than
NM_CONNECTION_ERROR here. Shall have no practical implications anyway.

(imported from NetworkManager commit cb28719e3a6f602a702f1665434d5c8b9aad3cec)

The shared files are GNU sources: they use glibc dynamic linker
specialties.

By now nobody should be using this. Keep the code around for a little
longer just in case anybody still uses this.

The libnm-glib support also serves as an example how do we build two
different versions of the properties plugin. We'll soon be in a similar
situation with Gtk 4.0. (sigh.) Just don't drop it yet.

!4

Don't build GNOME based properties if --without-gnome is specified.

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

[thaller@redhat.com: modified original patch for libnm-vpn-plugin-pptp.la]

It's nicer but also doesn't annoy gcc 8: "error: ‘strncpy’ specified bound
depends on the length of the source argument [-Werror=stringop-overflow=]"

!3

!2

!1

The pipeline begins with "build" stage doing a distcheck on Fedora 28
(which is still known to ship libnm-glib) and outputting a tarball
artifact.

The output is then used in the "test" stage.

In future, builds on some older platforms, CentOS and Ubuntu and clang
builds would be nice. Not implemented at this point, but it should be
straightforward enough.

Maybe a build with a Git snapshot of NetworkManager and/or
network-manager-applet would be useful at some point, but that's not
implemented either.

It's not necessarily present among the packages in a minimal
installation (such as Fedora's docker image). Worse even, libtool just
ends up not linking to some .la libraries.

Don't assume it's there.

It's a not necessarily present among the packages in a minimal
installation (such as Fedora's docker image). Worse even, configure just
ends up passing wrong linker flags on some architectures, without a word
of complain.

Don't assume it's there.

Autoconf installs it on autogen.

We're a compliant project and want automake to ensure we have NEWS,
INSTALL, etc. in the distribution.

We just need to disable portability warnings for the $(filter-out) GNU
make extension.