[libvirt] locking down struct size/layout in remote-protocol.x
Jim Meyering
jim at meyering.net
Tue May 11 05:56:37 UTC 2010
Eric Blake wrote:
> On 05/10/2010 02:36 PM, Jim Meyering wrote:
>> Eric Blake wrote:
>>> On 05/07/2010 03:23 PM, Jim Meyering wrote:
>>>> +remote_protocol-structs:
>>>> + $(AM_V_GEN)if pdwtags --help > /dev/null 2>&1; then \
>>>
>>> Some shells (at least Solaris /bin/sh) are noisy in spite of the
>>> redirections, when a program doesn't exist. I'm proposing a followup
>>> patch to clean up this invocation to use a subshell, and also to fix the
>>> subshell for cppi in cfg.mk.
>>
>> Or you could consider the noise a two-pronged feature:
That was semi-tongue-in-cheek.
>> - notify user that their $(SHELL) is inferior
>> - more noise about lack of a useful developer tool (pdwtags or cppi)
>
> In which case, your pdwtags usage is fine, and I should modify my patch
> to just drop the cppi subshell altogether?
"make syntax-check" (via maint.mk, cfg.mk etc) already relies on
shell features not available in Solaris' /bin/sh (e.g., $(command))
so dropping the cppi subshell would be fine. It is important for
readability (and my mental health ;-) to assume a good POSIX shell
for those rules, and that is fine, since only "developers" run
"make syntax-check", and we can require that they run "make" with
SHELL=/usr/local/bin/bash in a pinch.
pdwtags, however, is used as part of a rule run by "make check",
which is nominally subject to a higher standard. I was going to
say it *could* use a subshell, but then found that there are uses
of $(command) in "regular" makefiles, too:
$ git grep '\$\$('
cfg.mk: '\<$(func_re) *\([^"]*"[^"]*[a-z]{3}' $$($(VC_LIST_EXCEPT)) \
...
cfg.mk: stamp="$$($(_submodule_hash) $(_curr_status) 2>/dev/null)"; \
docs/Makefile.am: rm $(DESTDIR)$(DEVHELP_DIR)/$$(basename $$f); \
src/Makefile.am: $$(echo '$(libvirt_la_LDFLAGS)' \
Those last two would provoke syntax errors when building
with Solaris' /bin/sh, ...
So perhaps we really can just forget about those draconian
Solaris /bin/sh portability restrictions, at least here in libvirt.
More information about the libvir-list
mailing list