2018-10-03 21:06:57 +00:00
|
|
|
GPGME Python Bindings Documentation
|
|
|
|
===================================
|
|
|
|
|
|
|
|
As the GPGME Python bindings exist in two worlds within the FOSS
|
|
|
|
universe, it's always had a little issue with regards to its
|
|
|
|
documentation and specifically to the format of it. The GnuPG
|
|
|
|
Project, like much of the rest of the GNU Project, uses Texinfo to
|
|
|
|
build its documentation. While the actual format used to write and
|
|
|
|
edit that documentation is Org mode. Largely because most, if not
|
|
|
|
all, of the GnuPG developers use GNU Emacs for much of their work.
|
|
|
|
|
|
|
|
The Python world, however, utilises reStructuredText almost
|
|
|
|
universally. This in turn is used by Sphinx or Docutils directly to
|
|
|
|
build the documentation.
|
|
|
|
|
|
|
|
Each has various advantages for their own ecisystems, but this part of
|
|
|
|
the GnuPG effort is aimed at both sides. So, long story short, this
|
|
|
|
documentation is provided as both Texinfo and reStructuredText files.
|
|
|
|
|
|
|
|
This docs directory contains four main subdirectories:
|
|
|
|
|
|
|
|
1. meta
|
|
|
|
2. src
|
|
|
|
3. rst
|
|
|
|
4. texinfo
|
|
|
|
|
|
|
|
The Meta directory is for docs that are not intended for distribution
|
2018-11-06 05:22:50 +00:00
|
|
|
or are about the docs themselves. The sole exception being this
|
|
|
|
README file.
|
2018-10-03 21:06:57 +00:00
|
|
|
|
|
|
|
The Src directory is where the original edited files are, from which
|
|
|
|
the following two formats are generated initially. Most, if not all,
|
|
|
|
of these are written in Org Mode.
|
|
|
|
|
2018-11-06 05:22:50 +00:00
|
|
|
The ReST directory contains reStructuredText files which have been
|
2018-10-03 21:06:57 +00:00
|
|
|
converted to that format from the Org Mode files via Pandoc.
|
|
|
|
|
|
|
|
The Texinfo directory contains Texinfo files which have been exported
|
|
|
|
to that format from the Org Mode files by Org Mode itself within GNU
|
|
|
|
Emacs.
|
|
|
|
|
|
|
|
Those latter two directories should then be used by their respective
|
|
|
|
build systems to produce the various output file formats they normally
|
|
|
|
do. They should not spill out into this parent directory.
|
|
|
|
Particularly since it is quite possible, perhaps even likely, that
|
|
|
|
alternatives to both of them may be added to this parent documentation
|
|
|
|
directory at some future point.
|