New "configure" ncurses detection code

[Explorer09]

This PR is intended to supersede #1506

New detection code for curses library for configure.

• Both pkg-config and ncurses*-config will be used to find the compiler flags and linker flags for curses/ncurses. Fall back to simple -l<libname> linking if neither utilities are available.
• Environment variables CURSES_CFLAGS and CURSES_LIBS may be used to override the --cflags and -libs value.
• New configure option --with-curses=<libname> to specify the curses/ncurses module name. Should be used if the default detect list is not sufficient to find the library.

[Explorer09]

I found one possible room for improvement:

EDIT: This is done in a separate commit.

---

In the static build of htop (see this CI build log), -ltinfo is sometimes required (to be specified after -lncursesw) to link to ncurses. But our configure script detects tinfo after curses, which is probably of the cause of the configure error as seen in this build log in PR #1506.

Apparently the --libs output from pkg-config should be self-contained (with all the dependency libraries listed), but the detection would matter when pkg-config is not available.

[BenBE]

@explorer: Please don't use draft in a commit message. Commits should aim to be "the final product". If the patch series overall is not ready for merging yet, that's what the "draft" status of PRs is for.

On the patch series: LGTM. Maybe switch the order of the last two commits. If there's no objection from the OpenEmbedded people, I think we can go ahead with this one.

[Explorer09]

Please don't use draft in a commit message. Commits should aim to be "the final product". If the patch series overall is not ready for merging yet, that's what the "draft" status of PRs is for.

I say "draft" in the commit because I don't think I'm done yet, and to prevent accidental pulling. Don't worry, I'll remove that tag when I think I'm ready.

[Explorer09]

The configure script is revised and ready. However I got an unexpected configure error in OpenBSD build job in CI. It seems that OpenBSD build system in CI has pkg-config and libncursesw, but there is no ncurses.pc file describing the configuration. I can't tell if there is a package missing (to be installed) or if the system is designed that way.

[BenBE]

There's also a failure for Solaris AFAICS. Any intel on that one?

[Explorer09]

There's also a failure for Solaris AFAICS. Any intel on that one?

@BenBE I was testing whether htop can build on all BSD systems and Solaris with pkg-config installed. Ideally I want the ncurses compile and linker flags all grabbed from pkg-config, but some systems don't seem to provide the ncurses.pc file for us to use.

[BenBE]

Some minor notes on the current state of the patch:

diff --git a/configure.ac b/configure.ac
index 6347859f..7c9a745b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -383,11 +383,13 @@ dnl PKG_PROG_PKG_CONFIG initializes $PKG_CONFIG and related variables.
 dnl If the macro is not called, some pkg-config checks might be skipped
 dnl and $PKG_CONFIG might be unset.
 m4_ifdef([PKG_PROG_PKG_CONFIG], [
-PKG_PROG_PKG_CONFIG
+   PKG_PROG_PKG_CONFIG()
 ], [
-pkg_m4_absent=1
-m4_warn([syntax],
-   [pkg.m4 is absent or older than version 0.16; this 'configure' would have incomplete pkg-config support])
+   pkg_m4_absent=1
+   m4_warn(
+      [syntax],
+      [pkg.m4 is absent or older than version 0.16; this 'configure' will have incomplete pkg-config support]
+   )
 ])
 
 AC_ARG_ENABLE([unicode],
@@ -565,14 +567,14 @@ esac
 
 case ${htop_curses_capability}-$enable_unicode in
 none-*|nonwide-yes)
-   if test "x$PKG_CONFIG" = x; then (
+   if test "x$PKG_CONFIG" = x; then
       # Friendly warning to advise user to install pkg-config.
       # The local variables get discarded when done.
       list=""
       echo "" >conftest.c
       if test "$cross_compiling" != yes; then
          # "-print-multi-directory" supported in GCC 3.0 or later
-        name=""
+         name=""
          if $CC $CPPFLAGS $CFLAGS -print-multi-directory -E conftest.c >/dev/null 2>&1; then
             name=`$CC $CPPFLAGS $CFLAGS -print-multi-directory -E conftest.c 2>/dev/null |
                sed '/^ *#/ d; s/^\.$//; q'`
@@ -610,7 +612,7 @@ none-*|nonwide-yes)
             break
          fi
       done
-   ) fi
+   fi
 
    # OpenBSD and Solaris are known to not provide '*curses*.pc' files.
    AC_MSG_RESULT([no curses information found through '*-config' utilities; will guess the linker flags])
@@ -796,7 +798,7 @@ AC_DEFINE_UNQUOTED([OSRELEASEFILE], ["$with_os_release"], [File with OS release
 
 AC_ARG_WITH([config],
             [AS_HELP_STRING([--with-config=DIR],
-                           [configuration path @<:@default=/.config@:>@])],
+                            [configuration path @<:@default=/.config@:>@])],
             [],
             [with_config="/.config"])
 dnl Performance Co-Pilot configuration location to prevent overwrite
diff --git a/netbsd/README.md b/netbsd/README.md
index c319c199..30b344a1 100644
--- a/netbsd/README.md
+++ b/netbsd/README.md
@@ -13,8 +13,8 @@ NetBSD is one of the last operating systems to use and maintain its own
 implementation of Curses.
 
 htop(1) can be compiled against either ncurses or NetBSD's curses(3).
-htop(1) would use ncurses by default when it is found, as NetBSD's curses
-support in htop is limited.
+By default, htop(1) will use ncurses when it is found, as support for
+NetBSD's curses in htop is limited.
 
 To use NetBSD's libcurses, htop(1) must be configured with `--disable-unicode`.
 Starting with htop 3.4.0, a new option `--with-curses=curses` may be specified

[Explorer09]

Replying the suggestion from @BenBE.

The parentheses on that if block was intentional by me. This way I can isolate the local variables used within since all this block does is printing warning messages and it can all be done in a subshell.

[BenBE]

Reasonable. The way that scope is introduced just looks kinda strange without any annotation.

I'm also not sure if starting a subshell just for isolation is the right choice here or if braces ({}) might do the trick too …

[Explorer09]

The {} won't isolate local variables like I had originally intended.
If it was braces {} block, then it's no different from having no braces at all.

I wonder if I can make this code more obvious by turning into a shell function.