Remove Autotools config files and replace them by Meson

[jcfaracco]

Some containers (in special CentOS 8), there is a problem with Automake.
The NetworkManager fails to compile due to a bug. Since it has some
problems, it would be a nice opportunity to migrate to Meson build
system.

Signed-off-by: Julio Faracco jfaracco@br.ibm.com

[jcfaracco]

@grahamwhiteuk, I think it still requires some cleanups (remove M4 directory) and adjustments. But it is a nice opportunity to have it working before other GNOME/NM projects. Feel free to make any changes and suggestions.

[grahamwhiteuk]

Thanks @jcfaracco, I think it would be good to check what the intended future direction of Gnome/NM projects is. I see little point in straying from the current build system if all the related software is going to continue to use it. I'll send a message out on the NetworkManager mailing list to solicit opinion prior to considering whether we should look to merge this.

[grahamwhiteuk]

Documentation should be kept in line with the PR. Please update the README.md file and include this in the request.

[grahamwhiteuk]

The response I got from the NetworkManager list:

Hi Graham,

first of all, VPN plugins are entirely separate from NetworkManager,
they only need to implement the API. Meaning, what matters is that

• they talk the D-Bus API with NetworkManager.

• they can register themself towards NetworkManager with a file like
  /usr/lib/NetworkManager/VPN/*.name

• optionally, they provide a glib based shared library to integrate
  with libnm (as indicated in the .name file).

• optionally, the provide an auth-dialog (as indicated in the .name
  file).

that means, you can implement a VPN plugin in any language you deem
suitable (and use any build system).

Of course, there is some value in having all VPN plugins being similar
(e.g. using C, glib, libnm, libnma).

NetworkManager itself is primarily autotools and an experimental meson
setup. Probably one day, the meson setup will replace autotools
entirely. There is no timeline for that. One problem is that meson
eagerly bumps the python3 dependency, while we still want to build
NetworkManager on systems that are python2-only or use an older
python3. With time, this problem will probably go away.

For other components like VPN plugins, libnma and network-manager-
applet, the portability issue for meson is less of a concern. I think
it makes sense to switch those to meson-only today. Many GNOME projects
are already meson-only.

TL;DR: nowadays, I think it's fine for most projects to be meson-only.

best,
Thomas

Hence, I think we're green light to migrating from Autotools to Meson so I'll properly review the PR when I next get a chance.

[grahamwhiteuk]

I think .in files are supposed to be processed using the configuration_file directive, see https://mesonbuild.com/Configuration.html

[grahamwhiteuk]

I wanted to pick up from your great start here @jcfaracco so I've not merged this PR but created a new meson branch where I've continued hacking. I think this is in a pretty good state already but need to do some more testing. I can, at present, build the tree using meson and also build a source distribution and RPM build (through mock).