CI: Fix `configure.ac` help text where defaults are literal `dollar-varname` now

[jimklimov]

Check configure --help output: E_too_many_dollars.

Macros to process with/enable script arguments take their parameters literally (not substituting the default or previously-set values).

  --with-docs-man-section-api
                          man page section for library APIs
                          (${DEFAULT_MAN_SECTION_API})
  --with-docs-man-section-cfg
                          man page section for configuration files
                          (${DEFAULT_MAN_SECTION_CFG})
  --with-docs-man-section-cmd-sys
                          man page section for system management commands
                          (${DEFAULT_MAN_SECTION_CMD_SYS})
  --with-docs-man-section-cmd-usr
                          man page section for user commands
                          (${DEFAULT_MAN_SECTION_CMD_USR})
  --with-docs-man-section-misc
                          man page section for overviews, conventions, and
                          miscellaneous (${DEFAULT_MAN_SECTION_MISC})

  --with-statepath=PATH   path for ups state files (${STATEPATH}, typically
                          /var/state/ups)
  --with-altpidpath=PATH  path for NUT driver/upsd .pid files not running as
                          root (<statepath>)
  --with-pidpath=PATH     Path for root-owned .pid files (${PIDPATH},
                          typically /var/run)

Reword, maybe in a WET manner? Or use internet tricks with an m4_define() to both set the default value and report it as a variable expansion?

[jimklimov]

As found during work on #3133 there is a similar issue about variables pre-defined as verbatim expandable shell snippets, e.g. default confdir='${sysconfdir}${confdir_suffix}' where such text is only eval'uated later into a final string. This was tested to work via help-text default assignments if the backslash-dollar is used (so the nut_with_confdir variable gets assigned that verbatim shell snippet as desired), but help message looks even uglier (including those backslashes):

  --with-confdir-suffix   Relative path to NUT configuration files under
                          sysconfdir (auto)
  --with-confdir          Complete path to NUT configuration files
                          (\${sysconfdir}\${confdir_suffix})
  --with-confdir-examples Complete path to NUT configuration file examples
                          (some like it under datadir) (\${confdir})

Without backslashes, the current value of respective dollar-variable expansion becomes the nut_with_confdir value, which is not what we want at that point in configure script logic, e.g. NUT_ARG_WITH([confdir-examples], [help txt], [${confdir}]) ends up defining an empty nut_with_confdir_examples because a confdir is not defined at that point (nut_with_confdir might be, but this is not referenced here and may not be the final value we would be using).

At least for parameters defined with NUT helper m4 methods, NUT_ARG_WITH seems like the place to fix (expand once the added $1 ($3) help text formula?) Maybe add a method to the family (or two with NUT_ARG_ENABLE) which does such expansion explicitly where calling code wants it?..

[jimklimov]

Ultimately, this is not something that can be fully solved in autotools. As the *.ac/*.m4 script text gets parsed, outputs are directed into different buckets, with the pre-rendered verbatim block of help text being one of the first things to land into the final generated shell script.

Neat tricks like https://stackoverflow.com/questions/62406903/substitute-variable-into-m4-macro-when-running-autoconf suggested how to rewrite one text to another even in this context. The m4_esyscmd_s() can also get called to process active shell script - but only as much as conversion of fixed strings (like those backslash-dollar escapes). Appears to be called 3 times even, although maybe this becomes a sub-shell? At least the result does not seem to get cached so I could re-echo it next times.

There seems to be no way to apply this into reporting of values determined at run time (e.g. "--with-docs assumes same value as current --with-doc") because those variables are known and processed much later than the help text is factually printed. The SO trick above can be applied to m4_define m4 variables that can be used both for setting shell variable defaults and for help-text reports.

On a side note, it seems that callouts to methods defined with AC_DEFUN also tend to happen earlier than other (shell-ish) code in a method, which messes up what one thinks is a logical code path; see e.g. the recent split of a method in nut_check_python.m4 into a series of only AC_DEFUN'ed callouts with each running a bit of code - now in expected order.