[PATCH] Configure: introduced --without-libxslt

[Maxim Dounin]

Hello!

On Sat, May 06, 2023 at 06:03:15PM -0700, Dmitry Volyntsev wrote:

> On 06.05.2023 16:12, Maxim Dounin wrote:
>
> > On Fri, May 05, 2023 at 11:05:09PM -0700, Dmitry Volyntsev wrote:
> >
> >> # HG changeset patch
> >> # User Dmitry Volyntsev <xeioex at nginx.com>
> >> # Date 1683353037 25200
> >> #      Fri May 05 23:03:57 2023 -0700
> >> # Node ID 4891e0920d7c0e89def28694686e34294c69acf1
> >> # Parent  b71e69247483631bd8fc79a47cc32b762625b1fb
> >> Configure: introduced --without-libxslt.
> >>
> >> This allows to explicitly disable libxslt discovery by
> >> nginx and nginx addons.
> >>
> >> diff --git a/auto/lib/conf b/auto/lib/conf
> >> --- a/auto/lib/conf
> >> +++ b/auto/lib/conf
> >> @@ -29,8 +29,21 @@ if [ $USE_ZLIB = YES ]; then
> >>       . auto/lib/zlib/conf
> >>   fi
> >>   
> >> -if [ $USE_LIBXSLT != NO ]; then
> >> +if [ $USE_LIBXSLT != NO -a $USE_LIBXSLT != DISABLED ]; then
> >>       . auto/lib/libxslt/conf
> >> +
> >> +else
> >> +    if [ $USE_LIBXSLT = DISABLED -a $HTTP = YES -a $HTTP_XSLT = YES ]; then
> >> +
> >> +cat << END
> >> +
> >> +$0: error: the HTTP ngx_http_xslt_module requires the libxslt library.
> >> +You can either disable the module by using --without-http_xslt_module
> >> +option or you have to enable the libxslt support.
> >> +
> >> +END
> >> +        exit 1
> >> +    fi
> >>   fi
> >>   
> >>   if [ $USE_LIBGD != NO ]; then
> >> diff --git a/auto/modules b/auto/modules
> >> --- a/auto/modules
> >> +++ b/auto/modules
> >> @@ -277,7 +277,7 @@ if [ $HTTP = YES ]; then
> >>           . auto/module
> >>       fi
> >>   
> >> -    if [ $HTTP_XSLT != NO ]; then
> >> +    if [ $HTTP_XSLT != NO -a $USE_LIBXSLT != DISABLED ]; then
> >>           ngx_module_name=ngx_http_xslt_filter_module
> >>           ngx_module_incs=
> >>           ngx_module_deps=
> >> diff --git a/auto/options b/auto/options
> >> --- a/auto/options
> >> +++ b/auto/options
> >> @@ -363,6 +363,8 @@ use the \"--with-mail_ssl_module\" optio
> >>           --with-openssl=*)                OPENSSL="$value"           ;;
> >>           --with-openssl-opt=*)            OPENSSL_OPT="$value"       ;;
> >>   
> >> +        --without-libxslt)               USE_LIBXSLT=DISABLED       ;;
> >> +
> >>           --with-md5=*)
> >>               NGX_POST_CONF_MSG="$NGX_POST_CONF_MSG
> >>   $0: warning: the \"--with-md5\" option is deprecated"
> >
> > The only "without" configure option for libraries we use is
> > "--without-pcre", and it is disables PCRE library usage in the
> > nginx core (notably, regular expressions in server names and
> > locations).
> >
> > In contrast, the XSLT library is only used by the xslt filter
> > module, and the natural way to disable its usage is to don't
> > enable the module.  Similarly, OpenSSL, zlib, GD, and GeoIP
> > libraries are enabled by the corresponding modules, and not
> > enabled when the modules are not enabled.
> >
> > It is not clear why XSLT should be different, and how this is
> > expected to be used.
> 
> That is correct that XSLT library is only used for xslt filter.
> Nevertheless LIBXSLT is supported in ngx_module_libs for 3rd-party
> nginx modules, so for XSLT there are may be other uses outside of
> nginx core. Unlike OPENSSL and ZLIB which are essential parts of any
> modern nginx build, LIBXSLT is less commonly used and users
> sometimes want to disable LIBXSLT altogether.

As for the other libraries, the expected approach to disable 
the XSLT library usage is to disable modules which depend on it.

> What is the suggested way for a user to build 3rd-party module when
> he/she wants to specifically disable a part which needs LIBXSLT?
> 
> Alternatively there can be a way for nginx user building nginx to
> somehow signal to a 3rd-party module configure script what he/she wants.

As currently implemented, nginx expects an addon module to list 
libraries it depends on.  If a module normally depends on a 
library, but can be configured to do not depend on it, it is 
something to be configured on the module side.  A readily 
available solutions would be to pre-configure the module somehow, 
or use an environment variable to provide module-specific options.

We can consider implementing a way to provide module-specific 
configure options, but I don't think I remember [m]any requests 
for this.

-- 
Maxim Dounin
http://mdounin.ru/