[PATCH] gnumakefile: say ‘$(MAKE)’ not ‘make’

2020-08-01 Thread Paul Eggert
* top/GNUmakefile (abort-due-to-no-makefile): Prefer ‘$(MAKE)’ to ‘make’ in a diagnostic. This change is backported from Autoconf. --- ChangeLog | 7 +++ top/GNUmakefile | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 4917f3a1b..544563af2

Re: 'fdl' vs. 'fdl-1.3': difference and/or redundant?

2020-08-01 Thread Karl Berry
It would need to be applied upstream (maybe by Karl?). Not me, these days. Writing bug-standa...@gnu.org is the right thing to do. It seems to me that the root of the problem is that the fdl-1.3.texi in www is different from the fdl.texi in gnustandards. This should not ever have happened (no

Prefer documented autoconf macro 'm4_if' over 'ifelse'

2020-08-01 Thread Bruno Haible
The Autoconf equivalent to the m4 built-in macro 'ifelse' is not 'm4_ifelse' but 'm4_if'. Sometimes I remember this, sometimes I don't... 2020-08-01 Bruno Haible Prefer documented autoconf macro 'm4_if' over 'ifelse'. * m4/autobuild.m4 (AB_INIT): Use m4_if instead of ifelse.

Re: emacs-27.1-rc1 and UBsan findings

2020-08-01 Thread Jeffrey Walton
On Sat, Aug 1, 2020 at 4:23 PM Bruno Haible wrote: > > Hi Jeffrey, > > > Whoops, sorry. I attached the wrong archives. > > > > Here are the correct ones. > > The Emacs developers are listening on emacs-devel, not on bug-gnulib. Sorry about that. I think autocomplete bit me in the ass. Jeff

Re: emacs-27.1-rc1 and UBsan findings

2020-08-01 Thread Bruno Haible
Hi Jeffrey, > Whoops, sorry. I attached the wrong archives. > > Here are the correct ones. The Emacs developers are listening on emacs-devel, not on bug-gnulib. Bruno

emacs-27.1-rc1 and UBsan findings

2020-08-01 Thread Jeffrey Walton
I believe these additional failures are due to -fsanitize=undefined -fno-sanitize-recover=all. SUMMARY OF TEST RESULTS --- Files examined: 267 Ran 3850 tests, 7 failed to run, 3763 results as expected, 1 unexpected, 86 skipped 1 files did not contain any tests: src/emacs-modu

Re: Portability of libtextstyle

2020-08-01 Thread Bruno Haible
> 2020-08-01 Bruno Haible > > libtextstyle[-optional]: Allow requesting a minimum version. The tests need an update, too. Currently, a testdir creation produces this error: gllib/Makefile.am:272: error: GL_GENERATE_TEXTSTYLE_H does not appear in AM_CONDITIONAL 2020-08-01 Bruno Haibl

Re: Portability of libtextstyle

2020-08-01 Thread Akim Demaille
Hi Bruno! > Le 1 août 2020 à 15:10, Bruno Haible a écrit : > > In Bison's configure.ac, you now need to write > gl_LIBTEXTSTYLE_OPTIONAL([0.20.5]) > This will guarantee that you can use ostream_printf. If an older version of > libtextstyle is installed, it will not be used. > > > 2020-08-01

Re: parse-datetime: Fix compilation error with bison 3.7

2020-08-01 Thread Bruno Haible
> 2020-07-28 Bruno Haible > > parse-datetime: Fix compilation error with bison 3.7. > * modules/parse-datetime (Makefile.am): Create a generated header file > parse-datetime-gen.h in the source directory. Correct #include and > #line statements during preprocessing. Oop

Re: Portability of libtextstyle

2020-08-01 Thread Bruno Haible
Hi Akim, > > Having thought a while about it... I would prefer that users have > > the possibility to request any libtextstyle vs. request a libtextstyle > > which defines ostream_printf. > > > > There are two possibilities to implement that: > > (a) Turn 'libtextstyle' into a module which, addi