Building the man pages via xsltproc requires "docbook.xsl"
which is part of docbook.
Previously, we would build the man pages solely based on
"--enable-introspection", which checks for the presence of
xsltproc, but not docbook. This can lead to build failure
when docbook is not available, but "--enable-introspection"
is given.
Instead of adding yet another configure option to fine-tune
and say "--with-docbook --disable-gtk-doc", just simplify it.
Now, documentation (both man pages and setting docs) will be generated
with "--enable-gtk-doc" and "--enable-introspection".
If the documentation is not about to be generated, pre-generated docs
will be installed if they are available. That is commonly the case
with a source tarball, but not with a git checkout.
Finally, if documentation is nither generated nor pre-generated,
no documentation will be installed *duh*.
This removes the possibility to treat man pages separate from settings
docs. Now you either generate both, install both pre-generated, or don't
get any of them.
https://bugzilla.gnome.org/show_bug.cgi?id=778551
`nm` is used by "tools/create-exports-NetworkManager.sh" script.
Alloc configuring an explicit path during configure.
BINUTILS_NM=/usr/bin/nm ./configure
The new NMSettingMacsec contains information necessary to establish a
MACsec connection. At the moment we support two different MACsec
modes, both using wpa_supplicant: PSK and EAP.
PSK mode is based on a static CAK key for the MACsec key agreement
protocol, while EAP mode derives keys from a 802.1x authentication and
thus requires the presence of a NMSetting8021x in the connection.
Generating "src/NetworkManager.ver" each time seems to work well.
Thus, src/NetworkManager.ver-orig is unused an gets easily out
of date. Just remove it. It's not useful anymore.
As build-requirement, we either require
- python2 with python-gobject-base
- python3 with python3-gobject-base
Previously, we would require that a plain `python` gives the desired
interpreter version.
If somebody's "/usr/bin/env python" however points to a different
python version, there was no easy way to change it -- aside
resetting the $PATH variable to some desired "python" binary.
Now, you can specify it during configure:
./configure PYTHON=python3 ...
This especially matters, if you only have python3-gobject-base
installed, you /usr/bin/python is a symlink to python2.
https://bugzilla.gnome.org/show_bug.cgi?id=775768
Extend the D-Bus API and introduce a new NMDnsManager interface that
contains all the information related to DNS configuration.
At the moment the new DnsManager object only contains basic properties
describing the current DNS mode and resolv.conf manager.
Moving the PPP manager to a separate plugin that is loaded when needed
has the advantage of slightly reducing memory footprint and makes it
possible to install the PPP support only where needed.
https://bugzilla.gnome.org/show_bug.cgi?id=773482
- `make dist` requires --enable-gtk-doc --enable-introspection --with-libnm-glib
- --enable-gtk-doc requires --enable-introspection
- --with-nmcli requires either --enable-introspection or pregenerated
settings-docs.c files from the dist tarball. It does not require
--enable-gtk-doc.
There is a bit of a problem in that --enable-introspection requires
now xsltproc. However, gobject-introspection does itself not depend
on xsltproc. So, more correct might be a special --enable-doc argument,
that combines --enable-introspection --with-xsltproc. Anyway, that
seems to make it more complicated then it already is so just implicitly
(and surprisingly?) require xsltproc with --enable-introspection.
https://bugzilla.gnome.org/show_bug.cgi?id=775003
Need to pass --path to xsltproc to find common.ent in the
build-directory.
$ git clean -fdx && NMTST_MAKE='V=1 -d' ./tools/test-build.sh man/nm-settings-ifcfg-rh.xml
When building "libnm/nm-settings-docs.xml", we require
"nm-settings-docs-overrides.xml". As we dist the overrides files,
we must consult VPATH to locate the proper version of the file.
BUILT_SOURCES only matters during `make all`, `make check`
and `make install`.
It would be nice to be able to build every target specifically
from an empty git-tree.
Drop the use of BUILT_SOURCES where we already have the explicit
dependencies declared.
This makes it easier to install the files with proper names.
Also, it makes the makefile rules slightly simpler.
Lastly, the documentation is now generated into docs/api, which makes it
possible to get rid of the awkward relative file names in docbook.
Instead of relying on BUILT_SOURCES.
$ git clean -fdx && NOCONFIGURE=x ./autogen.sh && ./configure --enable-gtk-doc && make clients/cli/nmcli
Also, add the file to DISTCLEANFILES.
- Use -I$() instead of -I${}
- omit "top_" for -I$(srcdir)
- remove quoting for include paths
We don't quote other places either. You just cannot
build NetworkManager in a path that contain invalid
characters.
- remove trailing slash from include paths
- fix indention with spaces in Makefile.am
Keep the include paths clean and separate. We use directories to group source
files together. That makes sense (I guess), but then we should use this
grouping also when including files. Thus require to #include files with their
path relative to "src/".
Also, we build various artifacts from the "src/" tree. Instead of having
individual CFLAGS for each artifact in Makefile.am, the CFLAGS should be
unified. Previously, the CFLAGS for each artifact differ and are inconsistent
in which paths they add to the search path. Fix the inconsistency by just
don't add the paths at all.
We have generated headers, and non-generated.
We have public headers and internal headers.
We have headers/sources for libnm-glib and libnm-glib-vpn.
We want that non-generated files depend on generated files.
Thus, reorder it all and assign the groups to different variables.
Source files like libnm/nm-client.c include introspection files like
nmdbus-manager.h. These files are part of BUILT_SOURCES, which is
a pre-requisite to "all" target.
However, that is not sufficient for
./autogen --enable-gtk-doc && make dist
Generating the docs, requires man/nm-settings.xml. That is only present
when
- ./configure --enable-gtk-doc --with-introspecton
- in a dist-tarball, contrary to a git-tree
Only create docs, when we also regenerate the manuals (BUILD_SETTING_DOCS).
That is, you can no longer generate docs, by relying on the pre-generated
manual pages.
If you want to generate docs, you have to regenerate the manual pages
as well.
Previously, doing the following in a git-tree failed:
$ git clean -fdx
$ ./autogen.sh --enable-gtk-doc --enable-introspection=no && make
...
make[2]: Entering directory './NetworkManager/docs/api'
DOC Preparing build
DOC Scanning header files
DOC Introspecting gobjects
DOC Building XML
DOC Building XML
make[2]: *** No rule to make target '../../man/nm-settings.xml', needed by 'html-build.stamp'. Stop.
make[2]: Leaving directory './NetworkManager/docs/api'
This adds 0.4 seconds to the build time.
You can disable it by setting $NM_BUILD_NO_CREATE_EXPORTS environment
variable. This is useful in the unexpected case that the script
is broken.
Or, if you just want to use a different, non-generated version-script.
Or, if you want to save 0.4 seconds build-time.
This speeds up the initial object tree load significantly. Also, it
reduces the object management complexity by shifting the duties to
GDBusObjectManager.
The lifetime of all NMObjects is now managed by the NMClient via the
object manager. The NMClient creates the NMObjects for GDBus objects,
triggers the initialization and serves as an object registry (replaces
the nm-cache).
The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the
object creation, removal and property changes. It takes care of the
property changes so that we don't have to and lets us always see a
consistent object state. Thus at the time we learn of a new object we
already know its properties.
The NMObject unfortunately can't be made synchronously initializable as
the NMRemoteConnection's settings are not managed with standard
o.fd.DBus Properties and ObjectManager APIs and thus are not known to
the ObjectManager. Thus most of the asynchronous object property
changing code in nm-object.c is preserved. The objects notify the
properties that reference them of their initialization in from their
init_finish() methods, thus the asynchronously created objects are not
allowed to fail creation (or the dependees would wait forever). Not a
problem -- if a connection can't get its Settings, it's either invisible
or being removed (presumably we'd learn of the removal from the object
manager soon).
The NMObjects can't be created by the object manager itself, since we
can't determine the resulting object type in proxy_type() yet (we can't
tell from the name and can't access the interface list). Therefore the
GDBusObject is coupled with a NMObject later on.
Lastly, now that all the objects are managed by the object manager, the
NMRemoteSettings and NMManager go away when the daemon is stopped. The
complexity of dealing with calls to NMClient that would require any of
the resources that these objects manage (connection or device lists,
etc.) had to be moved to NMClient. The bright side is that his allows
for removal all of the daemon presence tracking from NMObject.
We'll soon not only do the router discovery, but announce ourselves as a
reouter. "Neighbor discovery" sounds to be a more appropriate name for
the class than "Router discovery".
This is especially important because we don't support
line continuation. Thus, with
FOO='val
bar=3'
wrong line
F2=b
F3='b
XXX=adf'
XXX2=val2
'
we now write
FOO=
#NM: FOO='val
bar=
#NM: bar=3'
#NM: wrong line
F2=b
F3=
#NM: F3='b
XXX=
#NM: XXX=adf'
XXX2=val2
#NM: '
Basically, the writer will comment out any line that is
- not all-whitespace
- not a '#' comment (possibly proceeded by whitespace)
- not a valid variable assignment
This avoids that writer writes lines that are not understood by
ifcfg-rh plugin, but interferes with initscripts. E.g.
NAME=old-name'
rm -rf /
'
becomes
NAME=new-name
#NM: rm -rf /
#NM: '
make[2]: Entering directory './NetworkManager/NetworkManager-1.5.1/_build/sub'
VAPIGEN vapi/libnm.vapi
Gio-2.0.gir:62318.7-62318.47: warning: Virtual method `G.Resolver.lookup_service_async' conflicts with method of the same name
Gio-2.0.gir:64704.7-64704.31: warning: Signal `G.Settings.change_event' conflicts with method of the same name
Gio-2.0.gir:84847.7-84851.24: error: `UnixSocketAddress' already contains a definition for `abstract'
Gio-2.0.gir:84690.7-84692.21: note: previous definition of `abstract' was here
Makefile:16410: recipe for target 'vapi/libnm.vapi' failed
Fixes: 0fa2cf19e5
NetworkManager and nm-iface-helper compiled nm-dhcp-manager.c twice,
the latter with setting -DNM_DHCP_INTERNAL_ONLY to only enable the
internal plugin.
Change that to compile nm-dhcp-manager.c once for both users
by putting it into libNetworkManagerBase.
We only needed proper glib enum types for having properties
and signal arguments. These got all converted to plain int,
so no longer generate such an enum type.