[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [virt-tools-list] [libosinfo v2 1/2] Add a private header



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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]