On 2024-08-17 07:54, Bruno Haible wrote:
Hi Paul,
[2]:
https://git.savannah.gnu.org/cgit/m4.git/commit/?h=branch-1.4&id=b357b798b04053df437b2df2f4f42dca69fb764c
Thanks. But now, in m4, there is a "make distcheck" failure:
...
An update of po/POTFILES.in is in order, I think. Like you did in
Marc Nieper-Wißkirchen wrote:
> > Yes. The shell-based implementation does not receive all bug-fixes and
> > improvements any more, and is deprecated.
>
> Thanks. Shouldn't the Python-based one be the default, then? An
> out-of-the-box checkout of gnulib seems to run the shell-based one.
Either
Am Sa., 17. Aug. 2024 um 15:00 Uhr schrieb Bruno Haible :
> Marc Nieper-Wißkirchen wrote:
> > > This is fixed now.
> > >
> >
> > What about the shell-based gnulib tool? Or should I consider that one
> > deprecated?
>
> Yes. The shell-based implementation does not receive all bug-fixes and
> improv
Hi Paul,
> [2]:
> https://git.savannah.gnu.org/cgit/m4.git/commit/?h=branch-1.4&id=b357b798b04053df437b2df2f4f42dca69fb764c
Thanks. But now, in m4, there is a "make distcheck" failure:
$ make distcheck
...
(cd po && make top_distdir=../m4-2021-05-16 distdir=../m4-2021-05-16/po \
am__remo
In continuous integration builds with clang (both an old clang 7
and a new clang 18 or 19-pre), I see three test failures:
FAIL: test-call_once2
FAIL: test-rwlock1
FAIL: test-lock
What's happening, is that clang, in the compilation unit of
glthread/lock.c, interprets the statements
#prag
Marc Nieper-Wißkirchen wrote:
> > This is fixed now.
> >
>
> What about the shell-based gnulib tool? Or should I consider that one
> deprecated?
Yes. The shell-based implementation does not receive all bug-fixes and
improvements any more, and is deprecated.
Bruno
Simon Josefsson wrote:
> > 'valgrindtests' would be a hack.
>
> How so?
Because glueing together two words is not common in the English language.
> However I also realize that the name is quite well established and has
> been in the gnulib manual for a long time.
Yes.
> >> The naming was a cle
Hi!
Bruno Haible schrieb am Sa., 17. Aug. 2024, 11:14:
> Hi Simon,
>
> > Ouch. Shouldn't we rename 'valgrind-tests' instead?
> > ...
> > Whatever problem appears if we rename
> > 'valgrind-tests' to, say, 'valgrindtests' we could fix.
>
> 'valgrindtests' would be a hack.
>
> 'valgrind-support-f
Bruno Haible writes:
> Hi Simon,
>
>> Ouch. Shouldn't we rename 'valgrind-tests' instead?
>> ...
>> Whatever problem appears if we rename
>> 'valgrind-tests' to, say, 'valgrindtests' we could fix.
>
> 'valgrindtests' would be a hack.
How so? The old name was a hack because it hijacked the *-te
Hi Simon,
> Ouch. Shouldn't we rename 'valgrind-tests' instead?
> ...
> Whatever problem appears if we rename
> 'valgrind-tests' to, say, 'valgrindtests' we could fix.
'valgrindtests' would be a hack.
'valgrind-support-for-tests' would have the same problem.
'test-support-with-valgrind' would
Bruno Haible writes:
> Hi Marc,
>
> Please keep the mailing list in CC.
>
>> > Does it still do so if you remove the 'valgrind-tests' modules from the
>> > list?
>> >
>>
>> It does not.
>
> OK, then the problem is that gnulib-tool does not know that 'valgrind-tests'
> is special. Fixed like this
11 matches
Mail list logo
