--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.