Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

Co-authored-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

This bumps the minimum required version of njs to 0.9.0

Cc: Sergey A. Osokin <sergey.osokin@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

You asked for a specific compression library, be clear when it isn't
found.

Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

-Wno-missing-field-initializers was needed for GCC 4.8 / RHEL 7 etc to
avoid warnings with {} empty initialisers.

We haven't needed to support that compiler for sometime.

Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

This allows to actually build unit with support for zlib, zstd and
brotli compression.

Any or all can be specified. E.g.

  $ ./configure --zlib ...

  $ ./configure --zlib --zstd --brotli ...

During configure you will see if support for the requested compressions
has been found and what version of the library is being used.

E.g.

  ...
  checking for zlib ... found
   + zlib version: 1.3.1.zlib-ng
  checking for zstd ... found
   + zstd version: 1.5.6
  checking for brotli ... found
   + brotli version: 1.1.0
  ...
  Unit configuration summary:
  ...
    zlib support: .............. YES
    zstd support: .............. YES
    brotli support: ............ YES
  ...

Co-authored-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

Now that we are able to use the "nonstring" variable attribute to quell
this warning, we no longer need to disable it.

The good thing is there was never a released version of GCC where the
warning couldn't be quelled by the attribute.

Fixes: 150378224 ("Fix build with GCC 15")
Cc: Alejandro Colomar <alx@kernel.org>
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

This is a wrapper around __attribute__ ((__nonstring__)). Traditionally
this was used to mark char array variables that intentionally lacked a
terminating NUL byte, this would then cause warning to either be quelled
or emitted for various memory/string functions.

GCC 15 introduced a new warning, Wunterminated-string-initialization,
which will always warn on things like

  static const char hex[16] = "0123456789ABCDEF";

However this is very much intentionally not NUL terminated.

When the Wunterminated-string-initialization patch went in, the
"nonstriong" attribute didn't quell this warning, however a patch has
since gone in (prior to the GCC 15 release) to enable this attribute to
quell this warning.

In Unit we disabled this new warning with an eye to being able to
re-enable it again, this patch is the first in a series to do just that.

So the above example would become

  static const char hex[16] NXT_NONSTRING = "0123456789ABCDEF";

Link: <https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=44c9403ed1833ae71a59e84f9e37af3182be0df5>
Link: <https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=622968990beee7499e951590258363545b4a3b57>
Link: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178#c21>
Cc: Alejandro Colomar <alx@kernel.org>
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

The upcoming GCC 15 release introduces a new compiler warning,
Wunterminated-string-initialization.

This is intended to catch things like

  static const u_char  hex[16] = "0123456789ABCDEF";

Where we are creating a character array from a string literal, but the
specified size is not enough for the terminating NUL byte.

In the above example that is intended as it is used as a lookup table
and only the individual indices are accessed.

As it happens, Unit uses the above idiom in a few places, triggering
this warning (which we treat as an error by default).

While I don't like disabling compiler warnings, lets just disable this
one temporarily, as there is a patch in the works to make the
"nonstring" variable attribute quell this warning.

We just disable this on GCC as this isn't in Clang and we don't need to
worry about older compilers as GCC silently ignores unknown -Wno-*
options.

Link: <https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=44c9403ed1833ae71a59e84f9e37af3182be0df5>
Link: <https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Common-Variable-Attributes.html>
Link: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178#c21>
Cc: Alejandro Colomar <alx@kernel.org>
Reviewed-by: Alejandro Colomar <alx@kernel.org>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>

There were at least a couple of issues with building OTEL support.

It only worked with GNU make due to the use of ifeq, even gmake had some
issues.

Debug builds were broken due to trying to pass --debug to cargo which is
the default and isn't a valid option.

This 'fixes' things by doing 'release' builds of OTEL by default.

Passing D=1 to make will generate 'debug' builds but this as previously
with D= etc, only works with GNU make.

We make use of the '--emit link=' rustc option to place the libotel.a
static library into build/lib

This is good, it consolidates the static libraries into one place and it
simplifies the build scripts.

While we're at it pretty print the cargo command by default.

Fixes: 9d3dcb800 ("otel: add build tooling to include otel code")
Link: <https://github.com/nginx/unit/pull/1520#issuecomment-2556265063>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>