Hello Dmitry,
Paul Eggert wrote:
> Attached is what I installed.
> diff --git a/pygnulib/__init__.py b/pygnulib/__init__.py
> index ca3685be49..d0e308ba0e 100644
> --- a/pygnulib/__init__.py
> +++ b/pygnulib/__init__.py
> @@ -31,5 +31,5 @@ Texinfo), assorted configuration scripts, and more. The
Hi Paul,
Thanks for going through the list.
But I believe that this one is wrong:
> diff --git a/lib/argp.h b/lib/argp.h
> index 7de939a2a1..404a631ca7 100644
> --- a/lib/argp.h
> +++ b/lib/argp.h
> @@ -407,7 +407,7 @@ struct argp_state
> unknown option is present, ARGP_ERR_UNKNOWN is return
On 07/06/2023 05:34, Jim Meyering wrote:
I noticed some syntax-check failures in diffutils.
Its uses of relatively new xinmalloc and xpmalloc functions triggered a
"make syntax-check" failure claiming that xalloc.h need not be included,
because none of its (old list) functions was used. This upda
The 'jikes' Java compiler had its final release more than 18 years ago [1].
Therefore there is no point any more in having it supported in the 'javacomp'
and 'javacomp-script' modules.
[1] https://en.wikipedia.org/wiki/Jikes
2023-06-09 Bruno Haible
javacomp: Remove support for 'jikes
The 'jview' JVM was present on Windows XP more than 15 years ago. Current
Windows versions don't have it any more. Therefore it's pointless to test
whether it's available.
2023-06-09 Bruno Haible
javaexec: Remove support for 'jview'.
* lib/javaexec.c (execute_java_class): Don'
GCC 7, released in 2017 (more than 6 years ago), dropped the support of gcj
and gij. And gcj and gij never supported Java 6. One can conclude that hardly
anyone has it still installed.
The support of gij and gcj in the modules 'javacomp' and 'javacomp-script'
complicates the support for more moder
This patch documents the possible values of the Java version, seen so far.
Tested with OpenJDK 9 .. 20.
2023-06-09 Bruno Haible
javaversion: Update comments.
* lib/javaversion.h (javaexec_version): Document the possible results up
to OpenJDK 20.
diff --git a/lib/javav
On 2023-06-09 03:38, Pádraig Brady wrote:
I think this misses xalloc_die due to the "extern"
adjustments in gnulib 3801e9bb67b.
It seems that the perl regexps in the comment need to be adjusted
to cater for the commented /*extern*/
Let's not bother. It's simpler to omit the /*extern*/ as it's
On 2023-06-09 02:11, Bruno Haible wrote:
- is set. INPUT is a pointer to a value to be passed in to the parser. */
+ is set. INPUT is a pointer to a value to be passed into the parser. */
Fine with me to change "into" to "to". ("in to" feels odd here.)
Paul Eggert wrote:
> > - is set. INPUT is a pointer to a value to be passed in to the parser.
> > */
> > + is set. INPUT is a pointer to a value to be passed into the parser. */
>
> Fine with me to change "into" to "to". ("in to" feels odd here.)
OK. Done.
On Fri, Jun 9, 2023 at 3:39 AM Pádraig Brady wrote:
> On 07/06/2023 05:34, Jim Meyering wrote:
> > I noticed some syntax-check failures in diffutils.
> > Its uses of relatively new xinmalloc and xpmalloc functions triggered a
> > "make syntax-check" failure claiming that xalloc.h need not be inclu
On 2023-06-08 21:09, Josh Soref wrote:
https://github.com/jsoref/gnu-gnulib/commit/142ff39f17f846808d018a1eb5e43d5e9ee7d2e6
Will someone else manage pulling in those bits? Or am I responsible for that?
The depcomp one is already done. I filed a bug report against the GNU
Coding Standards for
Paul Eggert wrote:
> It's simpler to omit the /*extern*/ as it's just noise
> in that context. I installed the attached.
top/maint.mk line 604 still does not catch 'xalloc_die'.
With this patch, it should do so.
2023-06-09 Bruno Haible
maint.mk: Regenerate regex to include xalloc_d
There's one ISO C header file that we don't have in the Gnulib documentation
so far: . Documented in
- ISO C 11 § 7.17,
- https://en.cppreference.com/w/c/atomic
This patch fixes that.
2023-06-09 Bruno Haible
doc: Document .
* doc/posix-headers/stdatomic.texi: New file.
14 matches
Mail list logo
