When compiling NetworkManager with --enable-gtk-doc outside the source tree, the generated documents are slightly different from those generated in tree. This patch fixes that missed COPYING file in $(top_builddir) and adds $(top_builddir)/libnm-util to DOC_SOURCE_DIR. https://bugzilla.gnome.org/show_bug.cgi?id=742139 Signed-off-by: You-Sheng Yang <vicamo@gmail.com>
Cleans up all of the warnings that aren't overly annoying to clean up.
As with NMVpnPluginOld, rename NMSecretAgent to NMSecretAgentOld, to leave the name "NMSecretAgent" open for a new-and-improved version in NM 1.2.
Since libnm-core secret-flags properties are now enum-typed rather than just being uints, we can now actually recognize them when generating docs, rather than just assuming that every property whose name ends in '-flags', but isn't in NMSettingDcb, is a secret-flags property.
Move the settings/plugins doc generation from libnm-util to libnm-core, since libnm-util isn't being updated for all new properties. With this commit, the keyfile and ifcfg-rh documentation is basically unchanged, except that deprecated properties are now gone, and new properties have been added, and the sections are in a different order. (generate-plugin-docs.pl just outputs the settings in Makefile order, and they were unsorted in libnm-util, but are sorted in libnm-core). The settings documentation used for nm-settings.5, the D-Bus API docs, and the nmcli help is changed a bit more at this point, and mostly for the worse, since the libnm-core setting properties don't match up with the D-Bus API as well as the libnm-util ones do. To be fixed... (I also removed the "plugins docs" line in each plugin docs comment block while moving them, since those blocks will be used for more than just plugins soon, and it's sort of obvious anyway.)
docs/api/settings-spec.xml was accidentally not getting disted, because gtk-doc.make explicitly removes all DISTCLEANFILES from distdir. However, it doesn't actually make sense for the settings docs files to be in DISTCLEANFILES anyway; they were put there rather than CLEANFILES (IIRC) so that "make clean" in a tarball build wouldn't delete them and break things. But the right fix is to just make them only be in CLEANFILES when BUILD_SETTING_DOCS is true, and not ever get deleted otherwise. Also adjust the build rules to ensure that the generated docs don't get rebuilt in tarball builds, since that can cause problems when building from a read-only source tree, etc. Meanwhile, in an unrelated but also fatal bug, configure.ac's check for if the generated docs were already present never got updated for the cli/src -> clients/cli move, and so even if we had been disting settings-spec.xml, configure would still think that the tarball didn't have all of the generated docs in it, so SETTING_DOCS_AVAILABLE would be set false and none of the generated docs would get used. https://bugzilla.gnome.org/show_bug.cgi?id=740035
Update the docs build to include and exclude the correct files. Fill in some missing documentation, and fix problems in the existing docs. (In particular, "<" can't appear as a literal in documentation, so change it to "<". Also, "PKCS#12" has to be written as "PKCS#<!-- -->12", or gtk-doc will think "#12" is a reference to a type named "12".)
As with NMIP4Config and NMIP6Config, merge the two DHCP config classes into one in the public API.
Create NMIPConfig as the parent of NMIP4Config and NMIP6Config, and remove the two subclasses from the public API; while it's convenient to still have both internally, they are now identical to the outside world.