On 2022-Aug-08, Tom Lane wrote:
> Alvaro Herrera writes:
> > Now that I did the translation chores again after a few years I am
> > reminded of a point about this argument: in reality, few people ever
> > run this recipe manually (I know I never do), because it's easier to
> > grab the already-
Alvaro Herrera writes:
> On 2022-Jul-28, Tom Lane wrote:
>> Thanks for testing it. I think the only remaining concern is
>> Peter's objection that $(wildcard) might pick up random junk files
>> that end in ".c". That's true, but the backend's nls.mk also
>> picks up everything matching "*.c" (ov
On 2022-Jul-28, Tom Lane wrote:
> Thanks for testing it. I think the only remaining concern is
> Peter's objection that $(wildcard) might pick up random junk files
> that end in ".c". That's true, but the backend's nls.mk also
> picks up everything matching "*.c" (over the whole backend tree,
>
Alvaro Herrera writes:
> In short, +1 to this patch.
Thanks for testing it. I think the only remaining concern is
Peter's objection that $(wildcard) might pick up random junk files
that end in ".c". That's true, but the backend's nls.mk also
picks up everything matching "*.c" (over the whole ba
On 2022-Jul-13, Tom Lane wrote:
> Actually, we can get rid of those easily enough anyway with $(sort).
> Here's a draft that might solve these problems. The idea is to use
> $(wildcard) for files in the srcdir, and manually enumerate only
> built files.
I checked the files in src/bin/scripts and
Peter Eisentraut writes:
> On 13.07.22 20:19, Tom Lane wrote:
>> Hmm. We could list built files explicitly, perhaps, and still be
>> a good step ahead on the maintenance burden. Does xgettext get
>> upset if the same input file is mentioned twice, ie would we have
>> to filter sql_help.c out of
On 13.07.22 20:19, Tom Lane wrote:
Hmm. We could list built files explicitly, perhaps, and still be
a good step ahead on the maintenance burden. Does xgettext get
upset if the same input file is mentioned twice, ie would we have
to filter sql_help.c out of the wildcard result?
It seems it wou
Peter Eisentraut writes:
> Note that we have this in nls-global.mk which tries to avoid having the
> vpath details sneak into the output:
> po/$(CATALOG_NAME).pot: $(GETTEXT_FILES) $(MAKEFILE_LIST)
> # Change to srcdir explicitly, don't rely on $^. That way we get
> # consistent #: file referenc
On 13.07.22 19:41, Tom Lane wrote:
Alvaro Herrera writes:
Hmm, I got this failure:
/usr/bin/xgettext: no se especificó el fichero de entrada
Hmm ... are you doing this in a VPATH setup? Does it help
if you make the entry be
GETTEXT_FILES= $(wildcard $(srcdir)/*.c)
I'd supposed we didn'
Peter Eisentraut writes:
> In some cases, the listed files are build output from another rule, for
> example sql_help.c. By using a wildcard, you just take whatever files
> happen to be there, not observing proper make dependencies.
Hmm. We could list built files explicitly, perhaps, and sti
On 13.07.22 20:09, Peter Eisentraut wrote:
In any case, someone should check that this creates identical output
before and after.
A quick check shows differences in
pg_rewind.pot
psql.pot
ecpg.pot
libpq.pot
plpgsql.pot
On 13.07.22 18:07, Tom Lane wrote:
Still, wildcarding the local *.c references seems like a clear step
forward. I'll go push that part.
In some cases, the listed files are build output from another rule, for
example sql_help.c. By using a wildcard, you just take whatever files
happen to be
Alvaro Herrera writes:
> Hmm, I got this failure:
> /usr/bin/xgettext: no se especificó el fichero de entrada
Hmm ... are you doing this in a VPATH setup? Does it help
if you make the entry be
GETTEXT_FILES= $(wildcard $(srcdir)/*.c)
I'd supposed we didn't need to be careful about that, be
On 2022-Jul-13, Tom Lane wrote:
> I had to recreate the patch almost from scratch, because 88dad06b4
> touched adjacent lines in most of these files, scaring patch(1)
> away from applying the changes. That being the case, I decided
> to use $(wildcard *.c) everywhere, including the places where t
I wrote:
> Kyotaro Horiguchi writes:
>> Since backend does that way, I think we can do that the same way
>> also for the tools. Attached second does that except for tools that
>> have only one *.c. The patch doesn't make a difference in the result
>> of make update-po.
> Still, wildcarding the l
Kyotaro Horiguchi writes:
> I find it annoying that make update-po stops at pg_upgrade on master.
> The cause is that a file is renamed from relfilenode.c to
> relfilenumber.c so just fixing the name works. (attached first).
Ooops.
> I wonder if we can use $(wildcard *.c) instead of explicitly
>
16 matches
Mail list logo
