public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* Re: x86: remove i386-opc.c
@ 2022-12-20  8:33 Alan Modra
  2022-12-20  8:40 ` Jan Beulich
  0 siblings, 1 reply; 7+ messages in thread
From: Alan Modra @ 2022-12-20  8:33 UTC (permalink / raw)
  To: binutils

Regen opcodes/po/POTFILES.in

diff --git a/opcodes/po/POTFILES.in b/opcodes/po/POTFILES.in
index 9906bf14848..effd73f8f78 100644
--- a/opcodes/po/POTFILES.in
+++ b/opcodes/po/POTFILES.in
@@ -73,7 +73,6 @@ h8300-dis.c
 hppa-dis.c
 i386-dis.c
 i386-gen.c
-i386-opc.c
 i386-opc.h
 ia64-asmtab.c
 ia64-asmtab.h

-- 
Alan Modra
Australia Development Lab, IBM

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: x86: remove i386-opc.c
  2022-12-20  8:33 x86: remove i386-opc.c Alan Modra
@ 2022-12-20  8:40 ` Jan Beulich
  2022-12-20 11:39   ` Alan Modra
  0 siblings, 1 reply; 7+ messages in thread
From: Jan Beulich @ 2022-12-20  8:40 UTC (permalink / raw)
  To: Alan Modra; +Cc: binutils

On 20.12.2022 09:33, Alan Modra via Binutils wrote:
> Regen opcodes/po/POTFILES.in
> 
> diff --git a/opcodes/po/POTFILES.in b/opcodes/po/POTFILES.in
> index 9906bf14848..effd73f8f78 100644
> --- a/opcodes/po/POTFILES.in
> +++ b/opcodes/po/POTFILES.in
> @@ -73,7 +73,6 @@ h8300-dis.c
>  hppa-dis.c
>  i386-dis.c
>  i386-gen.c
> -i386-opc.c
>  i386-opc.h
>  ia64-asmtab.c
>  ia64-asmtab.h

Which makes me wonder: If this is the list of files where string literals
may/will need translation, are files like i386-gen.c (i.e. build time
helper tool sources) really supposed to be enumerated here?

Jan

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: x86: remove i386-opc.c
  2022-12-20  8:40 ` Jan Beulich
@ 2022-12-20 11:39   ` Alan Modra
  2022-12-20 11:44     ` Jan Beulich
  2022-12-22  8:49     ` Jan Beulich
  0 siblings, 2 replies; 7+ messages in thread
From: Alan Modra @ 2022-12-20 11:39 UTC (permalink / raw)
  To: Jan Beulich; +Cc: binutils

On Tue, Dec 20, 2022 at 09:40:14AM +0100, Jan Beulich wrote:
> On 20.12.2022 09:33, Alan Modra via Binutils wrote:
> > Regen opcodes/po/POTFILES.in
> > 
> > diff --git a/opcodes/po/POTFILES.in b/opcodes/po/POTFILES.in
> > index 9906bf14848..effd73f8f78 100644
> > --- a/opcodes/po/POTFILES.in
> > +++ b/opcodes/po/POTFILES.in
> > @@ -73,7 +73,6 @@ h8300-dis.c
> >  hppa-dis.c
> >  i386-dis.c
> >  i386-gen.c
> > -i386-opc.c
> >  i386-opc.h
> >  ia64-asmtab.c
> >  ia64-asmtab.h
> 
> Which makes me wonder: If this is the list of files where string literals
> may/will need translation, are files like i386-gen.c (i.e. build time
> helper tool sources) really supposed to be enumerated here?

Probably not, but the build time tools don't tend to use gettext and
thus all it does is slow down generation of .pot files a little.

-- 
Alan Modra
Australia Development Lab, IBM

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: x86: remove i386-opc.c
  2022-12-20 11:39   ` Alan Modra
@ 2022-12-20 11:44     ` Jan Beulich
  2022-12-21 17:51       ` H.J. Lu
  2022-12-22  8:49     ` Jan Beulich
  1 sibling, 1 reply; 7+ messages in thread
From: Jan Beulich @ 2022-12-20 11:44 UTC (permalink / raw)
  To: Alan Modra, H.J. Lu; +Cc: binutils

On 20.12.2022 12:39, Alan Modra wrote:
> On Tue, Dec 20, 2022 at 09:40:14AM +0100, Jan Beulich wrote:
>> On 20.12.2022 09:33, Alan Modra via Binutils wrote:
>>> Regen opcodes/po/POTFILES.in
>>>
>>> diff --git a/opcodes/po/POTFILES.in b/opcodes/po/POTFILES.in
>>> index 9906bf14848..effd73f8f78 100644
>>> --- a/opcodes/po/POTFILES.in
>>> +++ b/opcodes/po/POTFILES.in
>>> @@ -73,7 +73,6 @@ h8300-dis.c
>>>  hppa-dis.c
>>>  i386-dis.c
>>>  i386-gen.c
>>> -i386-opc.c
>>>  i386-opc.h
>>>  ia64-asmtab.c
>>>  ia64-asmtab.h
>>
>> Which makes me wonder: If this is the list of files where string literals
>> may/will need translation, are files like i386-gen.c (i.e. build time
>> helper tool sources) really supposed to be enumerated here?
> 
> Probably not, but the build time tools don't tend to use gettext and
> thus all it does is slow down generation of .pot files a little.

Which then perhaps means we want to remove

#include <libintl.h>
#define _(String) gettext (String)

from i386-gen.c. H.J. - any idea why it was put there in the first place?

Jan

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: x86: remove i386-opc.c
  2022-12-20 11:44     ` Jan Beulich
@ 2022-12-21 17:51       ` H.J. Lu
  0 siblings, 0 replies; 7+ messages in thread
From: H.J. Lu @ 2022-12-21 17:51 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Alan Modra, binutils

On Tue, Dec 20, 2022 at 3:44 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 20.12.2022 12:39, Alan Modra wrote:
> > On Tue, Dec 20, 2022 at 09:40:14AM +0100, Jan Beulich wrote:
> >> On 20.12.2022 09:33, Alan Modra via Binutils wrote:
> >>> Regen opcodes/po/POTFILES.in
> >>>
> >>> diff --git a/opcodes/po/POTFILES.in b/opcodes/po/POTFILES.in
> >>> index 9906bf14848..effd73f8f78 100644
> >>> --- a/opcodes/po/POTFILES.in
> >>> +++ b/opcodes/po/POTFILES.in
> >>> @@ -73,7 +73,6 @@ h8300-dis.c
> >>>  hppa-dis.c
> >>>  i386-dis.c
> >>>  i386-gen.c
> >>> -i386-opc.c
> >>>  i386-opc.h
> >>>  ia64-asmtab.c
> >>>  ia64-asmtab.h
> >>
> >> Which makes me wonder: If this is the list of files where string literals
> >> may/will need translation, are files like i386-gen.c (i.e. build time
> >> helper tool sources) really supposed to be enumerated here?
> >
> > Probably not, but the build time tools don't tend to use gettext and
> > thus all it does is slow down generation of .pot files a little.
>
> Which then perhaps means we want to remove
>
> #include <libintl.h>
> #define _(String) gettext (String)
>
> from i386-gen.c. H.J. - any idea why it was put there in the first place?
>
> Jan

It is because _() is used in i386-gen.c.  We can remove its usage.

-- 
H.J.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: x86: remove i386-opc.c
  2022-12-20 11:39   ` Alan Modra
  2022-12-20 11:44     ` Jan Beulich
@ 2022-12-22  8:49     ` Jan Beulich
  2022-12-22  9:43       ` Alan Modra
  1 sibling, 1 reply; 7+ messages in thread
From: Jan Beulich @ 2022-12-22  8:49 UTC (permalink / raw)
  To: Alan Modra; +Cc: binutils

On 20.12.2022 12:39, Alan Modra wrote:
> On Tue, Dec 20, 2022 at 09:40:14AM +0100, Jan Beulich wrote:
>> On 20.12.2022 09:33, Alan Modra via Binutils wrote:
>>> Regen opcodes/po/POTFILES.in
>>>
>>> diff --git a/opcodes/po/POTFILES.in b/opcodes/po/POTFILES.in
>>> index 9906bf14848..effd73f8f78 100644
>>> --- a/opcodes/po/POTFILES.in
>>> +++ b/opcodes/po/POTFILES.in
>>> @@ -73,7 +73,6 @@ h8300-dis.c
>>>  hppa-dis.c
>>>  i386-dis.c
>>>  i386-gen.c
>>> -i386-opc.c
>>>  i386-opc.h
>>>  ia64-asmtab.c
>>>  ia64-asmtab.h
>>
>> Which makes me wonder: If this is the list of files where string literals
>> may/will need translation, are files like i386-gen.c (i.e. build time
>> helper tool sources) really supposed to be enumerated here?
> 
> Probably not, but the build time tools don't tend to use gettext and
> thus all it does is slow down generation of .pot files a little.

Irrespective of them using gettext (I've now queued a patch to remove
that from i386-gen.c), wouldn't it make sense to convert

POTFILES = $(HFILES) $(CFILES)

to

POTFILES = $(HFILES) $(LIBOPCODES_CFILES)

thus eliminating translation for build time tools regardless? At which
point the question would be whether CFILES as a variable needs retaining.
Afaics the definition of POTFILES is the only user.

Jan

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: x86: remove i386-opc.c
  2022-12-22  8:49     ` Jan Beulich
@ 2022-12-22  9:43       ` Alan Modra
  0 siblings, 0 replies; 7+ messages in thread
From: Alan Modra @ 2022-12-22  9:43 UTC (permalink / raw)
  To: Jan Beulich; +Cc: binutils

On Thu, Dec 22, 2022 at 09:49:41AM +0100, Jan Beulich wrote:
> On 20.12.2022 12:39, Alan Modra wrote:
> > On Tue, Dec 20, 2022 at 09:40:14AM +0100, Jan Beulich wrote:
> >> On 20.12.2022 09:33, Alan Modra via Binutils wrote:
> >>> Regen opcodes/po/POTFILES.in
> >>>
> >>> diff --git a/opcodes/po/POTFILES.in b/opcodes/po/POTFILES.in
> >>> index 9906bf14848..effd73f8f78 100644
> >>> --- a/opcodes/po/POTFILES.in
> >>> +++ b/opcodes/po/POTFILES.in
> >>> @@ -73,7 +73,6 @@ h8300-dis.c
> >>>  hppa-dis.c
> >>>  i386-dis.c
> >>>  i386-gen.c
> >>> -i386-opc.c
> >>>  i386-opc.h
> >>>  ia64-asmtab.c
> >>>  ia64-asmtab.h
> >>
> >> Which makes me wonder: If this is the list of files where string literals
> >> may/will need translation, are files like i386-gen.c (i.e. build time
> >> helper tool sources) really supposed to be enumerated here?
> > 
> > Probably not, but the build time tools don't tend to use gettext and
> > thus all it does is slow down generation of .pot files a little.
> 
> Irrespective of them using gettext (I've now queued a patch to remove
> that from i386-gen.c), wouldn't it make sense to convert
> 
> POTFILES = $(HFILES) $(CFILES)
> 
> to
> 
> POTFILES = $(HFILES) $(LIBOPCODES_CFILES)
> 
> thus eliminating translation for build time tools regardless? At which
> point the question would be whether CFILES as a variable needs retaining.
> Afaics the definition of POTFILES is the only user.

Sounds reasonable to me.

-- 
Alan Modra
Australia Development Lab, IBM

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-12-22  9:43 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-20  8:33 x86: remove i386-opc.c Alan Modra
2022-12-20  8:40 ` Jan Beulich
2022-12-20 11:39   ` Alan Modra
2022-12-20 11:44     ` Jan Beulich
2022-12-21 17:51       ` H.J. Lu
2022-12-22  8:49     ` Jan Beulich
2022-12-22  9:43       ` Alan Modra

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).