Eric Blake wrote: ... >>> -config_h_header ?= <config\.h> > > This is the kingpin line - add a definition of config_h_header in your > cfg.mk, and then maint.mk can be used unchanged but with your > alternative spelling of your common header (and also make sure your > osinfo/osinfo_priv.h includes config.h first). > >>> -sc_require_config_h: >>> - @require='^# *include $(config_h_header)' \ >>> +# osinfo_priv_h_header must be suitable for grep -E. >>> +osinfo_priv_h_header ?= <osinfo/osinfo_priv\.h> >>> +sc_require_osinfo_priv_h: >>> + @require='^# *include $(osinfo_priv_h_header)' \ >>> in_vc_files='\.c$$' \ >>> - halt='the above files do not include <config.h>' \ >>> + halt='the above files do not include <osinfo/osinfo_priv.h>' \ > > Don't change these - they will get undone the next time we resync from > upstream gnulib. > > Oh, that points out an upstream gnulib bug (cc'd) - the error message > here mentions <config.h> even when config_h_header has been customized. > I wonder if it is worth fixing in gnulib. Personally, I'm not inclined to change that. With a literal <config.h> in the diagnostic, we're correct for many projects. With $(config_h_header), either we're slightly wrong due to the fact that it's a regexp with probable backslash, and in general we cannot resolve that to a literal or literals -- or we punt and transform the name via s/\\//g, hoping to get it right. Or, adjust messages (probably making them longer) to say that we're talking about a regular expression. However, if you find a solution you're happy with, you're welcome to adjust those diagnostics.
