[PATCH] x86: Remove libopcodes dependency

[Jan Beulich]

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.

Therefore with my general maintainer hat on I object to such an approach.

If you really want to generate the files from gas/, then you should do
so there, i.e. also going as far as building i386-gen there. Once
again I did consider doing to, but deemed it awkward: Even if we don't
use libopcodes.{a,so} anymore, I think the opcode table processing
would better remain in opcodes/ - we'd use that library no longer as
a binary but as a (generated) source code one. If you think differently,
I wouldn't object to you following this alternative approach.

As a formal remark: In the description I would expect to be credited at
least for recognizing the opportunity; really you've re-used some of
what I've had in my patches, irrespective of you perhaps having done
things from scratch (and having spotted/corrected an oversight of mine,
which I was about to submit v3 of my series for, but which now I will
wait with until the above is settled - sadly meaning yet further delays
for the growing pile of other work I have pending on top).

Jan