Prev |  | Next

## H. Configure options

### Note

For more information about build environment setup, see chapters about Prerequisites for building NUT on different OSes (or `docs/config-prereqs.txt` in NUT sources for up-to-date information) and Custom NUT CI farm build agents: LXC multi-arch containers (or `docs/ci-farm-lxc-setup.txt` in NUT sources for up-to-date information).

As many other projects relying on GNU autotools for build recipe automation, NUT sources deliver a `configure` script which is used to set up numerous nuances relevant for your build of the project. Most of the configuration requirements are passed by `--with-something` or `--enable-something` options (allegedly, not always used consistently with autotools naming recommendations), and with environment variables like `CFLAGS` typically also passed as command line options.

Default syntax of `--with-something` or `--enable-something` assumes a boolean approach, so the option as such conveys a `yes` string value, and aliases `--without-something` or `--disable-something` are handled automatically as a `no` string value, for the option named `something`.

In many cases, these options are used to pass non-boolean configuration of the option in question, commonly a path, program name, compiler flags to use along with a particular dependency, user name or type of documentation to build, etc.

A special case here concerns options that accept an `auto` value, where the `configure` script would opine to request a final `yes` or `no`, depending on other circumstances of the build environment and requested configuration.

### 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 Packager Guide, which presents the best practices for installing and integrating NUT, is also a good reading.

The Prerequisites for building NUT on different OSes (or `docs/config-prereqs.txt` in NUT sources for up-to-date information) 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. Note that the `pkg-config` manifest `libupsclient.pc` does not easily convey this information.

Prev |  | Next
| Home |