Re: [PATCH] x86: Remove libopcodes dependency

["H.J. Lu" <hjl.tools@gmail.com>]

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.

> 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

Will do.

> 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).
>


-- 
H.J.