Hi Bruce,
> This time the tarball includes a module file of sorts.
Good, this is what gnulib needs.
> Makefile.am:
> GEN_ERRNO_FILES = err-names.c err-names.h
> BUILT_SOURCES += $(GEN_ERRNO_FILES)
> MOSTLYCLEANFILES += $(GEN_ERRNO_FILES)
> nodist_include_HEADERS += err-names.h
Does the .h file need to be generated? It is much more convenient to
rely on a .h file that is platform independent.
1) The user can look at the .h file to see whether it fits his needs,
and can start to program before doing "gnulib-tool --add-import ...;
./configure; make".
2) The user doesn't need to wonder whether the .h file contains different
function declarations on different platforms.
> err-names.c : err-names.h
> @test -f $@ || CC="$(CC)" $(SHELL) mk-err-names.sh
You need the C compiler for preprocessing, right? Then you shouldn't
forget about $(CPPFLAGS) and $(AM_CPPFLAGS). So change
CC="$(CC)"
to
CC="$(CC) $(AM_CPPFLAGS) $(CPPFLAGS)"
Also, the rule is not very robust and lacks dependencies: If one some
platform, the generation of the file fails, then you change mk-err-names.sh,
then retry "make", nothing will happen, because
1. err-names.c does not depend on mk-err-names.sh,
2. The "test -f $@ || ..." idiom will not rerun mk-err-names.sh.
I would recommend to use the well-tested idiom for generated files, like in
modules/unistd and many other places.
Also, the rule does not work in VPATH builds where $(srcdir) != ".".
> err-names.h : mk-err-names.sh $(EXE).c
> CC="$(CC)" $(SHELL) mk-err-names.sh
$(EXE) is undefined.
Bruno
--
In memoriam Maximilian Kolbe <http://en.wikipedia.org/wiki/Maximilian_Kolbe>
