--with-cgi (default: no)
Build and install the optional CGI programs, HTML files, and sample CGI configuration files. This is not enabled by default, as they are only useful on web servers. See data/html/README for additional information on how to set up CGI programs.
--with-doc=<output-format(s)> (default: no)
Build and install NUT documentation file(s).
This feature requires AsciiDoc 8.6.3 or newer (see https://asciidoc.org).
The possible documentation type values are:
html-single
for single page HTML,
html-chunked
for multi-paged HTML,
pdf
for a PDF file, and
man
for the usual manpages.
Other values understood for this option are listed below:
--with-doc
argument is passed without a list, or specifies
just =yes
or =all
, it enables all supported formats with a =yes
to require them.
--with-doc=auto
argument tries to enable all supported
formats with an =auto
but should not fail the build if something
can not be generated.
--with-doc=no
quietly skips generation of all types of documentation,
including manpages.
--with-doc=skip
is used to configure some of the make distcheck*
scenarios to re-use man page files built and distributed by the main
build and not waste time on re-generation of those.
Multiple documentation format values can be specified, separated with comma.
Each such value can be suffixed with =yes
to require building of this one
documentation format (abort configuration if tools are missing), =auto
to
detect and enable if we can build it on this system (and not abort if we
can not), and =no
(or =skip
) to explicitly skip generation of this
document format even if we do have the tools to build it.
If a document format is mentioned in the list without a suffix, then it is
treated as a =yes
requirement.
Verbose output can be enabled using: ASCIIDOC_VERBOSE=-v make
Example valid formats of this flag:
--with-doc
without an argument, effectively same as --with-doc=yes
--with-doc=
is a valid empty list, effectively same as --with-doc=no
--with-doc=auto
--with-doc=pdf,html-chunked
--with-doc=man=no,pdf=auto,html-single
NUT includes a client binding PyNUT
module, as well as an optional GUI
application NUT-Monitor
(not to be confused with nut-monitor
service
name for upsmon
as delivered by some OS distribution packages). Both
python 2.7 and several versions of python 3.x are supported and regularly
tested by NUT CI farm builds; other versions may work or not.
Also some of the source configuration (including activity in autogen.sh
script and later in certain Makefile`s during build) relies on presence
of `python
(and perl
) interpreters. If they are not available, e.g. on
older operating systems, certain features are skipped — but you may have
to export
special environment variables to signal to autogen.sh
that
this is an expected situation (it would suggest which, for your current
NUT version).
For CI builds (or similar reproducible developer activity) performed
with ci_build.sh
— since this is an area which impacts both configure
script generation by the helper autogen.sh
script and subsequently the
choices made by the configure
script itself, settings can be made by
exporting the PYTHON
environment variable which should evaluate to some
way to call the correct interpreter (e.g. python2.7
, /usr/bin/env python
or /usr/bin/python3
).
The configure
script does support equivalent options, whose defaults
come from detection of certain program names by current PATH
setting.
Further use of these interpreter names and other paths during NUT build
and installation is managed by Makefile variable expansion, as prepared
by the configure
script.
Also note that it is not required to use the same PYTHON
implementation
for autogen.sh
to do its job, and for the configure
script option.
As noted above, both python-2.x and python-3.x variants are supported.
You can consult the m4/nut_check_python.m4
file for detection methods used.
If both interpreter generations are present, and a particular un-versioned
PYTHON
is not specified or detected, then selected/detected PYTHON3
is
chosen as the ultimate PYTHON
value.
For majority of uses in the build procedure and products, the generation
of Python does not matter and the un-versioned PYTHON
value is substituted
into files as the script shebang, used to find the site-packages
location,
etc.
One exception is generation of NUT-Monitor GUI application which has been
separated for NUT-Monitor-py2gtk2
and NUT-Monitor-py3qt5
due to further
backend platform technical differences — these build products specifically
use PYTHON2
and PYTHON3
substitutions. They may be co-installed on the
same system. A dispatcher shell script NUT-Monitor
is used to launch the
preferred (newest) or the only existing implementation.
Please note that by default NUT tries to make use of everything in your
build environment, so if both Python generation are detected — the binding
module will be delivered into both, and two versions of NUT-Monitor GUI
application will be installed. If you want to avoid that behaviour on a
build system with both interpreters present, you can explicitly specify
to build e.g. --without-python2 --with-python=/usr/bin/python-3.9
.
The settings below may be of particular interest to non-distribution packaging efforts with their own dedicated directory trees:
--with-python=SHEBANG_PATH
Specify a definitive version you want used for majority of the Python code (except version-dependent scripts, see above).
The SHEBANG_PATH
should be a full program pathname, optionally with
one argument, e.g. /usr/bin/python-3.9
or /usr/bin/env python2
.
Defaults (in order):
* python
, python3
or python2
program if present in PATH
by such name,
* or the newest of PYTHON3
or PYTHON2
values (specified or detected below).
--with-python2=SHEBANG_PATH --with-python3=SHEBANG_PATH
For version-dependent scripts (see above) or to default the newest Python
version if not specified by --with-python
option or detected otherwise,
you can provide the preferred version and implementation of Python 2 or 3
respectively.
Conversely, if neither of these configure options were specified, but some
--with-python
program was specified or detected, and its report says it
has Python major version 2 or 3, then the versioned interpreter string would
point to that.
--with-nut_monitor
Install the NUT-Monitor GUI application (depending on Python 2 or 3 version
availability), and optional desktop-file-install
integration).
--with-pynut
Install the PyNUT module files for general consumption into "site-packages" location of the currently chosen Python interpreter(s): yes, no, auto. or dedicated as the required dependency of NUT-Monitor application (app).
The module files are installed into a particular Python version’s location
such as /usr/lib/python2.7/dist-packages
even if you specify a relaxed
or un-versioned interpreter like python2
(which would be used in scripts
for the NUT-Monitor application and possible other consumers of the module).
If the preferred Python version in the deployed system changes later (so the
python2
symlink for this example would point elsewhere) the module import
would become not resolvable for such consumers, until it is installed into
that other Python’s "site-packages" location.
--with-dev (default: no)
Build and install the upsclient and nutclient library and header files, to build further projects against NUT (such as wmNUT client and many others).
--enable-spellcheck (default: auto)
Activate recipes for documentation source file spelling checks with aspell
tool. Default behavior depends on availability of the tool, so if present — it would run for make check
by default, to facilitate quicker acceptance
of contributions.
--enable-check-NIT (default: no)
Add make check-NIT
to default activity of make check
to run the
NUT Integration Testing suite. This is potentially dangerous (e.g. due
to port conflicts when running many such tests in same environment),
so not active by default.
--enable-maintainer-mode (default: no)
Use maintainer mode to keep Makefile.in
and Makefile
in sync with
ever-changing Makefile.am
content after Git updates or editing.
--enable-cppcheck (default: no)
Activate recipes for static analysis with cppcheck
tools (if available).
--with-unmapped-data-points (default: no)
Build SNMP and USB-HID subdrivers with entries discovered by the scripts
which generated them from data walks, but developers did not rename yet
to NUT mappings conforming to docs/nut-names.txt
standards. Production
driver builds must not include any non-standard names.
--with-all (no default)
Build and install all of the above (the serial, USB, SNMP, XML/HTTP and PowerMan drivers, the CGI programs and HTML files, and the upsclient library).
--with-ssl (default: auto-detect) --with-nss (default: auto-detect) --with-openssl (default: auto-detect)
Enable SSL support, using either Mozilla NSS or OpenSSL.
If both are present, and nothing was specified, OpenSSL support will be preferred.
Read docs/security.txt for instructions on SSL support.
Currently the two implementations differ in supported features.
--with-wrap (default: auto-detect)
Enable libwrap (tcp-wrappers) support.
Refer to upsd(8) man page for more information.
--with-avahi (default: auto-detect)
Build and install Avahi support, to publish NUT server availability using mDNS protocol. This requires Avahi development files for the Core and Client parts.
--with-libltdl (default: auto-detect)
Enable libltdl (Libtool dlopen abstraction) support.
This is required to build nut-scanner
which loads third-party libraries
dynamically, based on requested scanning options. This allows to build and
package the tool without requiring all possible dependencies to be installed
in each run-time environment.