Re: [PATCH] x86: Remove libopcodes dependency

[Jan Beulich <jbeulich@suse.com>]

On 29.11.2022 00:43, H.J. Lu wrote:
> On Wed, Nov 23, 2022 at 12:36 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 22.11.2022 19:19, H.J. Lu wrote:
>>> --- a/gas/Makefile.am
>>> +++ b/gas/Makefile.am
>>> @@ -446,6 +446,12 @@ development.exp: $(BFDDIR)/development.sh
>>>       $(EGREP) "(development|experimental)=" $(BFDDIR)/development.sh  \
>>>         | $(AWK) -F= '{ print "set " $$1 " " $$2 }' > $@
>>>
>>> +$(srcdir)/../opcodes/i386-init.h $(srcdir)/../opcodes/i386-tbl.h: \
>>> +     @MAINT@ $(srcdir)/../opcodes/i386-opc.tbl \
>>> +     $(srcdir)/../opcodes/i386-reg.tbl \
>>> +     $(srcdir)/../opcodes/i386-opc.h
>>> +     cd ../opcodes; make gen-i386-tbl
>>
>> This recursing into a different directory (and then even using "cd" and
>> "make" instead of "$(MAKE) -C") is what I have specifically avoided in
>> my patches. This is deemed an anti-pattern by many people: If you
>> consider running make in just gas/ is an okay thing to do, then running
>> make in just opcodes/ is, too. Yet with such a rule doing so in parallel
>> can result in strange collisions and likely partially broken files.
> 
> "make" in opcodes won't regenerate these header files.  As far as make
> dependency is concerned,
> 
> $(MAKE) -C ../opcodes gen-i386-tbl
> 
> is like other programs.

No, it is not. There may be auxiliary files which get touched as a side
effect. There may also be some other entity (down the road) wanting to
do something similar, which may end up conflicting. Plus you shouldn't
set a bad precedent. My objection remains. I'm actually puzzled that
you've now submitted a v2 of your patch _after_ having made me (by
remaining silent there) _once again_ waste time on submitting a new
version of a series you (apparently) mean to reject in the end. I don't
mind you wanting things done differently, but then please say so. I
did specifically wait a few days to give you time to reply one way or
another.

Jan