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?