bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problems in Emacs with GL_GENERATE_STDINT_H


From: Bruno Haible
Subject: Re: problems in Emacs with GL_GENERATE_STDINT_H
Date: Sat, 18 Dec 2021 14:55:53 +0100

Hi Paul,

> * There seem to be similar issues with modules/fnmatch's 
> "gl_CONDITIONAL_HEADER([fnmatch.h])" duplicating fnmatch-h, 
> modules/glob's "gl_CONDITIONAL_HEADER([glob.h])" duplicating glob-h, and 
> modules/iconv_open's "gl_CONDITIONAL_HEADER([iconv.h])".

Yes, there are in total 4 occurrences (currently) of this idiom:

modules/fnmatch:gl_CONDITIONAL_HEADER([fnmatch.h])
modules/glob:gl_CONDITIONAL_HEADER([glob.h])
modules/iconv_open:gl_CONDITIONAL_HEADER([iconv.h])
modules/stdint:gl_CONDITIONAL_HEADER([limits.h])

> I worked around the problem by installing the attached patch.

The patch is not right. If we have, in this order,
  1. an invocation of gl_LIMITS_H that happens to set
     GL_GENERATE_LIMITS_H to false,
  2. an invocation of gl_CONDITIONAL_HEADER([limits.h]) from the
     'limits' module,
  3. an invocation of gl_REPLACE_LIMITS_H, from the 'stdint'
     module,
the Automake invocation will substitute variables
GL_GENERATE_LIMITS_H_TRUE and GL_GENERATE_LIMITS_H_FALSE that
have been computed from step 1, not from step 3.

> this resulted in 'configure' failing with the diagnostic "*** 
> GL_GENERATE_LIMITS_H is not set correctly".

Oops; this is unexpected.

> I tried using the latest Gnulib with Emacs and ran into a problem.

Unfortunately, you didn't tell how to reproduce it. In a current emacs git
checkout, I ran
  $ admin/merge-gnulib $GNULIB_SRCDIR
  $ grep GL_GENERATE_LIMITS_H configure
  GL_GENERATE_LIMITS_H
      GL_GENERATE_LIMITS_H=false
      GL_GENERATE_LIMITS_H=true
    GL_GENERATE_LIMITS_H=true
    case "$GL_GENERATE_LIMITS_H" in
      *) echo "*** GL_GENERATE_LIMITS_H is not set correctly" 1>&2; exit 1 ;;
    $GL_GENERATE_LIMITS_H && GL_GENERATE_LIMITS_H=1 || GL_GENERATE_LIMITS_H=
    case "$GL_GENERATE_LIMITS_H" in
      *) echo "*** GL_GENERATE_LIMITS_H is not set correctly" 1>&2; exit 1 ;;
    $GL_GENERATE_LIMITS_H && GL_GENERATE_LIMITS_H=1 || GL_GENERATE_LIMITS_H=

As you can see, there is
  - one expansion of gl_LIMITS_H, that sets GL_GENERATE_LIMITS_H to
    false or true.
  - Then there is an expansion of gl_REPLACE_LIMITS_H, that sets it true always.
  - Then come two copies of gl_CONDITIONAL_HEADER([limits.h]).
But what are the
  '$GL_GENERATE_LIMITS_H && GL_GENERATE_LIMITS_H=1 || GL_GENERATE_LIMITS_H='
lines??

The macro gl_CONDITIONAL_HEADER is written in such a way that it can be
invoked twice. It is not exactly idemponent, because it needs to handle
the case that the first invocation is for the lib/ directory and the
second invocation is for the tests/ directory.

> The resulting 'configure' script executed two copies of the following code:
> 
>    case "$GL_GENERATE_STDINT_H" in 
>      false) STDINT_H='' ;; 
>      true) 
>                    if test -z "$STDINT_H"; then 
>          STDINT_H="${gl_source_base_prefix}stdint.h" 
>        fi 
>        ;; 
>      *) echo "*** GL_GENERATE_STDINT_H is not set correctly" 1>&2; exit 1 ;;
>    esac 

This is harmless.

The error message (which I can't reproduce) occurs when
gl_CONDITIONAL_HEADER([limits.h]) comes before any of gl_LIMITS_H and
gl_REPLACE_LIMITS_H.

>    $GL_GENERATE_STDINT_H && GL_GENERATE_STDINT_H=1 || GL_GENERATE_STDINT_H=

> * Should the shell script use a different variable name for the "1" vs 
> "" value, than for the "true" vs "false" value? This might help avoid 
> similar confusion in the future.

Where do these lines come from? They apparently arise from the
AM_CONDITIONAL invocation. But /usr/share/aclocal-1.16/cond.m4
produces different code for AM_CONDITIONAL than this one.

It comes from emacs' configure.ac !!!

  AC_DEFUN([AM_CONDITIONAL],
    [$2 && $1=1 || $1=
     AC_SUBST([$1])])

The original AM_CONDITIONAL macro supports a condition that has the
same name as a shell variable, e.g.
  AM_CONDITIONAL([FOO], [$FOO])
The emacs overridden one does not!

So, that is the problem.

There are two ways to fix this:
  (A) Change Emacs AM_CONDITIONAL to support equal names.
  (B) Change 27 Gnulib modules to use different names for the
      conditional variable.

My preference (by far) is (A). Change emacs/configure.ac to use this:

  AC_DEFUN([AM_CONDITIONAL],
    [$2 && $1_CONDITION=1 || $1_CONDITION=
     AC_SUBST([$1_CONDITION])])

and at the same time, change gnulib-tool through the attached patch.

Bruno

Attachment: 0001-stdint-Fix-handling-of-limits.h-regression-2021-12-1.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]