On Wed, May 22, 2024 at 08:12:04AM +0200, Helmut Grohne wrote: > Hi Thomas, > > On Tue, May 21, 2024 at 03:06:00PM -0400, Thomas Dickey wrote: > > hmm - there are two sets of changes - I don't see a reason for the > > change to the curses function checks. > > Thank you for reviewing my patch. The curses function check change does > have a reason. It can be solved differently in principle. > > When I ran autoheader, config.hin would lack all the defines that should
I don't use autoheader (though it's present in the fork I've maintained for about the past quarter-century). The configure script generates the complete dlg_config.h without that crutch. Attempting to bypass that will certainly lead to unnecessary bug reports. > have come from CF_CURSES_FUNCS while the relevant HAVE_* defines would > still show up in config.log after running configure and therefore the > resulting dlg_config.h would also lack them. That meant that dialog > would perceive a very dysfunctional curses and its shim would fail to > compile. Quite clearly, we shouldn't assume a crippled curses and > config.hin should contain the relevant templates. As it turns out, > autoheader interprets the m4 files and collects the AC_DEFINE and > AC_DEFINE_UNQUOTED invocations, well some of them actually. The > AC_CHECK_FUNCS would be collected whereas CF_CURSES_FUNCS not, even > though both seemed quite similar. The subtle difference is that > AC_CHECK_FUNCS uses AS_FOR (a loop that is evaluated using m4) whereas Actually it would be AC_FOREACH, which invokes AH_TEMPLATE fwiw, CF_CURSES_FUNCS predates that stuff (1997 versus 1999), and there are other macros which might use those features. (I added a to-do to follow up on this) > CF_CURSES_FUNCS uses a shell for loop. Thus, autoheader would only see a > single, bogus AC_DEFINE_UNQUOTED for all of CF_CURSES_FUNCS and ignore > that. Avoiding this shell loop is key here and I went for manually > unrolling it, because AS_FOR didn't work out initially and unrolling > seemed workable to me. The crucial bit here is that you cannot use shell > for control flow here. If you prefer AS_FOR or some other working > mechanism, that's fine. Just do something about it to avoid dialog > failing to build when we remove libtool-bin from Debian. > > Helmut > -- Thomas E. Dickey <dic...@invisible-island.net> https://invisible-island.net
signature.asc
Description: PGP signature
