Re: stdint generation

[Bruno Haible]

Hello Ralf,

Thanks for explaining how this can work. I didn't know that
"config.status --file=..." was applicable also to files that are not
mentioned by AC_CONFIG_FILES.

Ralf Wildenhues wrote:
> you'd go to:
> 
>   # We need the following in order to create <stdint.h> when the system
>   # doesn't have one that works with the given compiler.
>   stdint.h: stdint.in.h
>           cd $(top_builddir) && ./config.status 
> '--file=$(subdir)/$@:$(abs_srcdir)/stdint.in.h'
>   MOSTLYCLEANFILES += stdint.h

Changing the current directory is not necessary. It also seems to work
like this:

  stdint.h: stdint.in.h
          $(top_builddir)/config.status '--file=stdint.h:$(srcdir)/stdint.in.h'
  MOSTLYCLEANFILES += stdint.h

> and then the first line of stdint.in.h could read
>   /* @configure_input@ */
> 
> which, when substituted, will sound a bit less harsh than your current
> warning; if you want to keep the exact warning, then I guess nothing
> keeps you from
>   AC_SUBST([gnulib_configure_input],
>    [DO NOT EDIT! GENERATED AUTOMATICALLY!])

Yes, we want to keep the exact warning. It is a compromise between Jim
and me.

You can call this variable @GNULIB_TEMPLATE@:

  AC_SUBST([GNULIB_TEMPLATE], [DO NOT EDIT! GENERATED AUTOMATICALLY!])

> Note that, this way, the rebuild semantics have not changed at all:
> stdint.h is not listed in AC_CONFIG_FILES, it does not get created at
>   ./config.status
> 
> time.  The only consequence would be less typing in modules/stdint, and
> a bit slower build (because config.status would be executed for each
> replacement header).

A slower build is acceptable: There are not so many *.in.h files.

But I'm worried about the error handling if the disk is full while processing
this rule. It's really annoying when, say, unistd.h comes out empty and
the user then has to hunt down the reason for many warnings and errors.
What I see in an autoconf 2.61 generated config.status is this:

  sed "/^[       ]*VPATH[        ]*=/...." $ac_file_inputs \
    | sed ... | sed ... | sed -f "$tmp/subs-5.sed" > $tmp/out

and the error status of the last command is ignored. Can you fix this for
2.62?

> Of course, generation at the end of `configure' could be a further step:
> use
>   AC_CONFIG_FILES([$sourcebase/stdint.h])
> 
> and add $(top_builddir)/config.status to the list of dependencies of the
> above rule.  This would only be telling the truth: the dependency exists
> already now, in current gnulib, however it's not spelled out

There are two problems:

  - Is it possible to use AC_CONFIG_FILES conditionally? I.e.

       if test $gl_cv_stdint_correct = no; then
         AC_CONFIG_FILES([$sourcebase/stdint.h:$sourcebase/stdint.in.h])
       fi

    Will automake do the right thing with this?

  - The dependency to config.status will cause all *.h files to be rebuilt
    upon reconfiguration, leading to an avalanche of recompilations of .o
    files. For config.h this is avoided through a simple logic in config.status:

    if diff $ac_file "$tmp/config.h" >/dev/null 2>&1; then
      { echo "$as_me:$LINENO: $ac_file is unchanged" >&5
echo "$as_me: $ac_file is unchanged" >&6;}
    else
      rm -f $ac_file
      mv "$tmp/config.h" $ac_file
    fi

    But this logic exists only for CONFIG_HEADERS, not for CONFIG_FILES.

Therefore I would refrain from using AC_CONFIG_FILES here.

> If you like any of the two steps, I can prepare a patch for them.

Yes, doing the first step through config.status is very welcome. Please!

Bruno