Currently neither Autoconf nor Automake provide direct Gperf support, but interfacing Gperf with them is straightforward.
configure.ac needs to do is to look for
to provide its definition for Makefiles via
Autoconf.). In fact, using Automake's macro to put
the control of
missing is enough:
Makefile.am should include:
# Handling the Gperf code GPERFFLAGS = --compare-strncmp --switch=1 --language=ANSI-C BUILT_SOURCES = atoms.c atoms.c: atoms.gperf if $(GPERF) $(GPERFFLAGS) --key-positions=1,3,4 --struct-type \ atoms.gperf >$@t; then \ mv $@t $@; \ elif $(GPERF) --version >/dev/null 2>&1; then \ rm $@t; \ exit 1; \ else \ rm $@t; \ touch $@; \ fi
I personally avoid using short options in scripts and Makefiles, because
short options are likely to change and because long options are easier
to understand when you don't know the program. Do not forget to help
Automake understand that
atoms.c is to be built early (before its
gperf is a maintainer requirement: someone
changing the package needs it, but its result is shipped so that a
regular user does not need it. Hence, we go through some hoops in order
to ensure that a failed run of
gperf doesn't erase the
maintainer's pre-built copy of
missing would have
handled these details gracefully.
There are three cases to handle:
@t, as the actual output,
$(GPERF)invocation failed, but
$(GPERF) --versionsucceeded, then this is certainly an actual error in the input file. In this case, do not hide the failure and exit with failure.
$(GPERF)does not answer to
--version, it is certainly missing, and
missingalready suggested to install Gperf. Then remove the temporary output file, and let the compilation proceed by updating the timestamp of the output file. That's a best effort, essentially helping users who get the project with broken timestamps.