configure.txt

ifdef::website[]
Configure options
=================
endif::website[]

[NOTE]
======
When building NUT from Git sources rather than the distribution tarballs,
you would have to generate the `configure` script and some further needed
files by running `./autogen.sh`. This in turn may require additional tools
and other dependencies on your build environment (referenced just a bit
below). For common developer iterations, porting to new platforms,
or in-place testing, running the `./ci_build.sh` script can be a helpful
one-stop solution.
+
The NUT linkdoc:packager-guide[Packager Guide], which presents the best
practices for installing and integrating NUT, is also a good reading.
+
The link:config-prereqs.txt[Prerequisites for building NUT on different OSes]
document suggests prerequisite packages with tools and dependencies
available and needed to build and test as much as possible of NUT on
numerous platforms, written from perspective of CI testing (if you
are interested in getting updated drivers for a particular device,
you might select a sub-set of those suggestions).
======

There are a few options reviewed below that can be given to `configure`
script to tweak your compilations. See also `./configure --help` for a
current and complete listing for the current version of the codebase.

NUT tracks `configure` options used during build, so you can view them
to produce a replacement by asking NUT programs for `--help` or for
`--version` with debugging enabled (first), e.g.:

----
:; upsd -DV
Network UPS Tools upsd 2.8.1
Network UPS Tools version 2.8.1 configured with flags: --with-all=auto --with-doc=skip ...
----

A more industrial approach is to use `lib/libupsclient-config --config-flags`
where supported.

Keeping a report of NUT configuration
-------------------------------------

	--enable-keep_nut_report_feature

If this option is enabled (not currently default), the report displayed
by `configure` script will be kept in a file when the script ends, and
installed into the data directory.

In-place replacement defaults
-----------------------------

A common situation for NUT builds is to verify whether current version
of the codebase (e.g. recent and not-yet-packaged release, or a Git branch)
solves some issues of an existing deployment. Such tests are simplified
if the new build of NUT plays by the same systems integration rules as
the already deployed (e.g. package-delivered) version, specifically about
filesystem access permissions and configuration file locations.

	--enable-inplace-runtime

Tries to detect and pre-set `configure` defaults for run-time settings
(which you can still override if needed, but no longer *must* specify
explicitly to be on same page as the existing setup), e.g.:

* --sysconfdir
* --with-user
* --with-group

If the installed NUT version supports reporting of `CONFIG_FLAGS` used
during its build, the `configure` script will try to take those values
into account when running in this mode.

NOTE: This does not currently rely on the configuration report optionally
installed by `--enable-keep_nut_report_feature` above, but might do so
eventually.

Driver selection
----------------

Serial drivers
~~~~~~~~~~~~~~

	--with-serial

USB drivers
~~~~~~~~~~~

Build and install the serial drivers (default: yes)

	--with-usb

Build and install the USB drivers (default: auto-detect)

Note that you need to install the libusb development package or files,
and that both libusb 0.1 and 1.0 are supported. In case both are
available, libusb 1.0 takes precedence, and will be used by default.
It is however possible to override this default choice by explicitly
calling `--with-usb=libusb-0.1` or `--with-usb=libusb-1.0`.
If you do specify the version to use (or `yes` for auto-detection),
this option would fail if requested (or any) libusb version was not
found.  The default `auto` value would not fail in such case.

SNMP drivers
~~~~~~~~~~~~

	--with-snmp

Build and install the SNMP drivers (default: auto-detect)

Note that you need to install libsnmp development package or files.

	--with-net-snmp-config

In addition to the `--with-snmp` option above, this one allows to provide
a custom program name (in `PATH`) or complete pathname to `net-snmp-config`
(may have copies named per architecture, e.g. `net-snmp-config-32` and
`net-snmp-config-64`).

This may be needed on build systems which support multiple architectures,
or in cases where your distribution names this program differently.
With a default value of `yes` it would mean preference of this program,
compared to information from `pkg-config`, if both are available.

XML drivers and features
~~~~~~~~~~~~~~~~~~~~~~~~

	--with-neon

Build and install the XML drivers (default: auto-detect)

Note that you need to install neon development package or files.

LLNC CHAOS Powerman driver
~~~~~~~~~~~~~~~~~~~~~~~~~~

	--with-powerman

Build and install Powerman PDU client driver (default: auto-detect)

This allows to interact with the Powerman daemon, and the numerous
Power Distribution Units (PDU) supported by the
https://github.com/chaos/powerman[powerman] project.

Note that you need to install powerman development package or files.

IPMI drivers
~~~~~~~~~~~~

	--with-ipmi
	--with-freeipmi

Build and install IPMI PSU driver (default: auto-detect)

This allows to monitor numerous Power Supply Units (PSU) found on servers.

Note that you need to install freeipmi (0.8.5 or higher, for nut-scanner;
and 1.0.1 or higher, for nut-ipmipsu) development package or files.

I2C bus drivers
~~~~~~~~~~~~~~~

	--with-linux_i2c

Build and install i2c drivers (default: auto-detect)

Note that you need to install libi2c development package or files.

GPIO bus drivers
~~~~~~~~~~~~~~~~

	--with-gpio

Build and install GPIO drivers (default: auto-detect)

Note that on Linux you need to install libgpiod library and development package
or files. This seems to be present in distributions released after roughly 2018.
Other platforms are not currently supported, but may be in the future.

Modbus drivers
~~~~~~~~~~~~~~

	--with-modbus

Build and install modbus (Serial, TCP) drivers (default: auto-detect)

Note that you need to install libmodbus development package or files.

Manual selection of drivers
~~~~~~~~~~~~~~~~~~~~~~~~~~~

	--with-drivers=<driver>,<driver>,...

Specify exactly which driver or drivers to build and install (this
works for serial, usb, and snmp drivers, and overrides the
preceding three options).

As of the time of original writing (2010), there are 46 UPS drivers
available.  Most users will only need one, a few will need two or
three, and very few people will need all of them.

To save time during the compile and disk space later on, you can
use this option to just build and install a subset of the drivers.
For example, to select `mge-shut` and `usbhid-ups`, you'd do this:

	--with-drivers=apcsmart,usbhid-ups

If you need to build more drivers later on, you will need to rerun
`configure` with a different list. To make it build all of the
drivers from scratch again, run `make clean` before starting.


Optional features
-----------------

CGI client interface
~~~~~~~~~~~~~~~~~~~~

	--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 link:data/html/README[] for additional
information on how to set up CGI programs.

Pretty documentation and man pages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

* If the `--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.

* An (explicit!) `--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.

* A `--with-doc=no` quietly skips generation of all types of documentation,
  including manpages.

* A `--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.

* A `--with-doc=dist-auto` allows to use pre-distributed MAN pages if present
  (should be in "tarball" release archives; should not be among Git-tracked
  sources; may be left over from earlier builds in same workspace), or build
  those if we can (the `auto` part). Practically this is implemented in detail
  only for `--with-doc=man=dist-auto`, as we do not dist HTML and PDF products;
  it is a placeholder for those to simplify the generic configuration calls.

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`

Python support
~~~~~~~~~~~~~~

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

NOTE: 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).

[WARNING]
=========
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.
=========

Development files
~~~~~~~~~~~~~~~~~

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

Options for developers
~~~~~~~~~~~~~~~~~~~~~~

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

	--enable-NUT_STRARG-always (default: auto)

Enable the `NUT_STRARG` macro (to handle `NULL` string printing) even
if the system libraries seem to safely support this behavior natively?
This flag should primarily help against overly zealous static analysis
tools in recent compiler generations.  The `auto` value enables the flag
for certain compiler versions known to complain about some of our use
cases -- even though those seem to be false positives.


I want it all!
~~~~~~~~~~~~~~

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

Networking transport security
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

	--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 link:docs/security.txt[] for instructions on SSL support.

NOTE: Currently the two implementations differ in supported features.

Networking access security
~~~~~~~~~~~~~~~~~~~~~~~~~~

	--with-wrap (default: auto-detect)

Enable libwrap (tcp-wrappers) support.

Refer to linkman:upsd[8] man page for more information.

Networking IPv6
~~~~~~~~~~~~~~~

	--with-ipv6 (default: auto-detect)

Enable IPv6 support.

AVAHI/mDNS
~~~~~~~~~~

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

LibLTDL
~~~~~~~

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

Other configuration options
---------------------------

NUT data server port
~~~~~~~~~~~~~~~~~~~~

	--with-port=PORT

Change the TCP port used by the network code.  Default is 3493
as registered with IANA.

Ancient versions of `upsd` used port 3305.  NUT 2.0 and up use a
substantially different network protocol and are not able to
communicate with anything older than the 1.4 series.

If you have to monitor a mixed environment, use the last 1.4 version,
as it contains compatibility code for both the old "REQ" and the new
"GET" versions of the protocol.

Daemon user accounts
~~~~~~~~~~~~~~~~~~~~

	--with-user=<username>
	--with-group=<groupname>

See also `--enable-inplace-runtime`.

Programs started as `root` will `setuid()` to `<username>` for somewhat
safer operation.  You can override this with `-u <otheruser>` in several
programs, including `upsdrvctl` (and all drivers by extension), `upsd`,
and `upsmon`.  The "user" directive in `ups.conf` overrides this at run
time for the drivers.

NOTE: `upsmon` does not totally drop `root` because it may need to
initiate a shutdown.  There is always at least a stub process
remaining with `root` powers.  The network code runs in another
(separate) process as the new user.

The `<groupname>` is used for the permissions of some files,
particularly the hotplugging rules for USB. The idea is that the
device files for any UPS devices should be readable and writable by
members of that group.

The default value for both the username and groupname is `nobody`
(or `nogroup` on systems that have it when `configure` script runs).
This was done since it's slightly better than staying around as
`root`.  Running things as `nobody` is not a good idea, since it's a
hack for NFS access.  You should create at least one separate user
for this software.

If you use one of the `--with-user` and `--with-group` options, then
you have to use the other one too.

See the link:INSTALL.nut[] document and the FAQ for more on this topic.

Syslog facility
~~~~~~~~~~~~~~~

	--with-logfacility=FACILITY

Change the facility used when writing to the log file.  Read the man
page for `openlog` to get some idea of what's available on your system.
Default is `LOG_DAEMON`.


Installation directories
------------------------

	--prefix=PATH

This is a fairly standard option with GNU autoconf, and it sets the
base path for most of the other install directories.  The default
is `/usr/local/ups`, which puts everything but the state sockets in one
easy place, and does not conflict with usual distribution packaging.

If you like having things to be at more of a "system" level, setting
the prefix to `/usr/local` or even `/usr` might be better.

	--exec_prefix=PATH

This sets the base path for architecture dependent files. By
default, it is the same as `<prefix>`.

	--sysconfdir=PATH

Changes the location where NUT's configuration files are stored.
By default this path is `<prefix>/etc`.  Setting this to `/etc/nut` or
`/etc/ups` might be useful. See also `--enable-inplace-runtime`.

The `NUT_CONFPATH` environment variable overrides this at run time.

	--sbindir=PATH
	--bindir=PATH

Where executable files will be installed. Files that are normally
executed by root (`upsd`, `upsmon`, `upssched`) go to `<sbindir>`,
all others to `<bindir>`. The defaults are `<exec_prefix>/sbin` and
`<exec_prefix>/bin` respectively.

See also `--with-drvpath` below.

	--with-drvpath=PATH

The UPS drivers will be installed to this path.  By default they
install to `<exec_prefix>/bin`, i.e. `/usr/local/ups/bin`.

You would want a location that remains mounted when most of the system
is prepared to turn off, so some distributions package NUT drivers into
`/lib/nut` or similar. See link:config-notes.txt[] detailing how to
set up system shutdown.

The `driverpath` global directive in the `ups.conf` file overrides this
at run time.

	--datadir=PATH

Change the data directory, i.e., where architecture independent
read-only data is installed.  By default this is `<prefix>/share`,
i.e. `/usr/local/ups/share`.  At the moment, this directory only
holds two files -- the optional `cmdvartab` and `driver.list`.

	--mandir=PATH

Sets the base directories for the man pages.  The default is
`<prefix>/man`, i.e. `/usr/local/ups/man`.

	--includedir=PATH

Sets the path for include files to be installed when `--with-dev` is
selected. For example, `upsclient.h` is installed here. The default
is `<prefix>/include`.

	--libdir=PATH

Sets the installation path for libraries.  Depending on the build
configuration, this can include the `libupsclient`, `libnutclient`,
`libnutclientsub`, `libnutscan` and their pkg-config metadata (see
`--with-pkgconfig-dir` option). The default is `<exec_prefix>/lib`.

	--libexecdir=PATH

Sets the installation path for "executable libraries" -- helper scripts
or programs that are not intended for direct and regular use by people,
and rather are implementation details of services.  Depending on the
build configuration, this can include the `nut-driver-enumerator.sh`,
`sockdebug`, and others. The default is `<exec_prefix>/libexec`.

Package distributions may want to use this option to customize this path
to include the package name, e.g. set it to `<exec_prefix>/libexec/nut`.

	--with-pkgconfig-dir=PATH

Where to install pkg-config `*.pc` files. This option only has an
effect if `--with-dev` is selected, and causes a pkg-config file to
be installed in the named location. The default is
`<exec_prefix>/pkgconfig`.

Use `--without-pkgconfig-dir` to disable this feature altogether.

	--with-cgipath=PATH

The CGI programs will be installed to this path.  By default, they
install to `<exec_prefix>/cgi-bin`, which is usually
`/usr/local/ups/cgi-bin`.

NOTE: If you set the prefix to something like `/usr`, you should set the
`cgipath` to something else, because `/usr/cgi-bin` is pretty ugly and
non-standard.

The CGI programs are not built or installed by default.  Use
`./configure --with-cgi` to request that they are built and
installed.

	--with-htmlpath=PATH

HTML files will be installed to this path. By default, this is
`<prefix>/html`. Note that HTML files are only installed if
`--with-cgi` is selected.

	--with-hotplug-dir=PATH

Where to install Linux 2.4 hotplugging rules. The default is to use
`/etc/hotplug`, if that directory exists, and to not install it
otherwise. Note that this installation directory is not a
subdirectory of `<prefix>` by default. When installing NUT as a
non-root user, you may have to override this option.

Use `--without-hotplug-dir` to disable this feature altogether.

	--with-udev-dir=PATH

Where to install Linux 2.6 hotplugging rules, for kernels that have
the "udev" mechanism. The default is to use `/etc/udev`, if that
directory exists, and to not install it otherwise. Note that this
installation directory is not a subdirectory of `<prefix>` by
default. When installing NUT as a non-root user, you may have to
override this option.

Use `--without-udev-dir` to disable this feature altogether.

	--with-systemdsystemunitdir=PATH

Where to install Linux systemd unit definitions. Useless and harmless
on other OSes, including Linux distributions without systemd, just adding
a little noise to configure script output.

Use `--with-systemdsystemunitdir=auto` (default) to detect the settings
using pkg-config if possible.

Use `--with-systemdsystemunitdir(=yes)` to require detection of these
settings with pkg-config, or fail configuration if not possible.

Use `--with-systemdsystemunitdir=no` to disable this feature altogether.

	--with-systemdshutdowndir=PATH

Where to install Linux systemd unit definitions for shutdown handling.
Useless and harmless on other OSes, including Linux distributions
without systemd, just adding a little noise to configure script output.

Use `--with-systemdshutdowndir` to detect the settings using pkg-config.

Use `--with-systemdshutdowndir=no` to disable this feature altogether.

	--with-systemdtmpfilesdir=PATH

Where to install Linux systemd configuration for tmpfiles handling (the
automatically created locations for PID, state and similar run-time files).
Useless and harmless on other OSes, including Linux distributions
without systemd, just adding a little noise to configure script output.

Use `--with-systemdtmpfilesdir` to detect the settings using pkg-config.

Use `--with-systemdtmpfilesdir=no` to disable this feature altogether.

	--with-libsystemd=(auto|yes|no)
	--with-libsystemd-includes=CFLAGS
	--with-libsystemd-libs=LDFLAGS

If the build system provides `libsystemd` headers, NUT binaries can be
built with tighter integration to this service management framework.
In this case NUT daemons (`upsd`, `upsmon`, `upslog` and drivers) would
report their life-cycle milestones (`READY`, `RELOADING`, `STOPPING`) and
support the watchdog reports (if enabled in their respective units by
end-user -- not done by default since the numbers depends on monitoring
system performance). Default: "auto" (integration enabled if detected).

	--with-augeas-lenses-dir=PATH

Where to install Augeas configuration-management lenses.

Only useful and valid if you use Augeas to parse and modify configuration
files. The default is to use `/usr/share/augeas/lenses`, if that directory
exists, and to not install it otherwise.


Directories used by NUT at run-time
-----------------------------------

	--with-pidpath=PATH

Changes the directory where NUT pid files are stored for processes running
as `root`.  By default this is `/var/run`.  Certain programs like `upsmon`
will leave files here.

	--with-altpidpath=PATH

Programs that normally don't have `root` powers, like the drivers and
`upsd`, write their pid files here.  By default this is whatever the
statepath (below) is, as those programs should be able to write there.

The `NUT_ALTPIDPATH` environment variable overrides this at run time.

	--with-statepath=PATH

Change the default location of the state sockets created by the drivers
to interact with the data server `upsd`. Default is `/var/state/ups`.

The `NUT_STATEPATH` environment variable overrides this at run time.

	--with-powerdownflag=FILEPATH

Change the default location (full filename path) of the POWERDOWNFLAG
created by `upsmon` (as `root`) to tell the late-shutdown integration
that this machine should tell all UPSes for which it is a "primary" NUT
server to cut power to the load. Default is `/etc/killpower` on POSIX
systems and `"C:\\killpower"` (note the double backslashes) on Windows.

Things the compiler might need to find
--------------------------------------

LibGD
~~~~~

	--with-pkg-config

This option allows to provide a custom program name (in `PATH`) or a
complete pathname to `pkg-config` which describes `CFLAGS`, `LIBS` and
possibly other build-time options in `*.pc` files, to use third-party
libraries. On build systems which support multiple architectures you
may also want to set `PKG_CONFIG_PATH` to match your current build.

	--with-gd-includes="-I/foo/bar"

If you installed `libgd` in some place where your C preprocessor can't
find the header files, use this switch to add additional `-I` flags.

	--with-gd-libs="-L/foo/bar -labcd -lxyz"

If your copy of `libgd` isn't linking properly, use this to give the
proper `-L` and `-l` flags to make it work.  See `LIBS=` in gd's `Makefile`.

NOTE: the `--with-gd` switches are not necessary if you have gd 2.0.8
or higher installed properly.  The `gdlib-config` script or pkg-config
manifest will be detected and used by default in that situation.

	--with-gdlib-config

This option allows to provide a custom program name (in `PATH`) or
a complete pathname to `gdlib-config`. This may be needed on build
systems which support multiple architectures, or in cases where your
distribution names this program differently.

LibUSB
~~~~~~

	--with-libusb-config

This option allows to provide a custom program name (in `PATH`) or
a complete pathname to `libusb-config` (usually delivered only for
libusb-0.1 version, but not for libusb-1.0). This may be needed on
build systems which support multiple architectures or provide several
versions of libusb, or in cases where your distribution names this
program differently.

Various
~~~~~~~

	--with-ssl-includes, --with-usb-includes, --with-snmp-includes,
	--with-neon-includes, --with-libltdl-includes,
	--with-powerman-includes="-I/foo/bar"

If your system doesn't have pkg-config and support for any of the above
libraries isn't found (but you know it is installed), you must specify
the compiler flags that are needed.

	--with-ssl-libs, --with-usb-libs, --with-snmp-libs,
	--with-neon-libs, --with-libltdl-libs
	--with-powerman-libs="-L/foo/bar -labcd -lxyz"

If system doesn't have pkg-config or it fails to provides hints for
some of the settings that are needed to set it up properly and the
build in defaults are not right, you can specify the correct values
for your system here.