If we have ENABLE_GTK_DOCS, but not BUILD_SETTING_DOCS, nm-settings.5
nm-settings-keyfile.5 and nm-settings-ifcfg-rh.5 would not be installed.
(It happened on RHEL 7 build, due to missing BuildRequires: pygobject3-base)
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
man/nm-settings-keyfile.xml is generated via an XSLT stylesheet applied to
libnm-util/nm-keyfile-docs.xml. Then a manual page is generated from the XML.
Certain build configurations (like --enable-gtk-doc
--disable-introspection) were broken with respect to nm-setting-docs.
Fix this. Also, we don't require just gobject-introspection, we need
pygobject specifically as well.
doing:
./configure --disable-gtk-doc
make clean
make
from a tarball build (or from a dirty tree that had previously had an
--enable-gtk-doc build) would fail, because configure would see the
pre-existing man pages and set INSTALL_PREGEN_MANPAGES, but "make
clean" would delete them, and there'd be no rule to regenerate them.
dist tarballs shouldn't ever be released without the documentation,
and this allows us to build the tarballs with pre-generated docs
that get installed on the end system, but don't need to be built
there. So the end system doesn't need gtk-doc installed, only
the dist system does.
https://bugzilla.gnome.org/show_bug.cgi?id=700093
DocBook is not my favorite thing in the world, but it's
<lots-of-emphasis>far</lots-of-emphasis> saner than troff. Some style
parts cribbed from systemd.
This is preparatory work for actually improving the content of the
man pages.
In that mode, we shouldn't attempt to generate any manpages. While
we're here, rewrite this file (using nonrecursive style) so we don't
install non-generated ones either.
Signed-off-by: Colin Walters <walters@verbum.org>
* Makefile.am, configure.in: Add new man subdirectory.
* man, man/NetworkManager.1.in, man/NetworkManagerDispatcher.1.in,
man/Makefile.am: Add man pages for NetworkManager and its
crime-solving bumbling buddy, NetworkManagerDispatcher.
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@1367 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
