Why does gnulib use makefile rules rather than configure?

[Paul Smith]

I'm looking at allowing GNU make to use more gnulib facilities, but
I've run into a serious problem.

It seems that a lot of gnulib modules rely on makefile rules added to
Makefile.in to construct files, rather than using traditional configure
replacement .in file conversions.

This is a real issue for me because I've always provided a shell
script, build.sh, which can be used to bootstrap an instance of make if
the user doesn't already have one.

The build.sh script relies on the user first running configure to
detect all the normal system-specific behaviors and generate the
standard configure output files such as config.h etc., but then instead
of running "make" (which they don't have), they run ./build.sh.

However, when using gnulib this no longer works because many gnulib
modules seem to delegate various configuration operations to the
generated makefile, rather than using configure to do it.

As a simple example, consider alloca-opt.  gnulib provides alloca.in.h
then adds a Makefile.am rule to convert it to alloca.h, that uses sed
to replace one value:

  sed -e 's|@''HAVE_ALLOCA_H''@|$(HAVE_ALLOCA_H)|g'

The prevalence of this type of behavior in gnulib means that I either
have to give up on using gnulib with GNU make, or else give up on
providing a bootstrapping script.


I don't see why these replacements couldn't instead be done via
configure and its built-in replacement facilities.  Why can't we add
these headers as AC_CONFIG_FILES() and allow them to be generated by
the configure script, instead of requiring makefile rules to do it?