[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