Collin Funk wrote:
> I've updated the gnulib-tool-tests in the maint-tools repository with
> the output of gnulib-tool.py [1].
Thanks. That is helpful.
Bruno
Git version 2.43 likes to give a verbose hint about the default branch
name, when one uses 'git init'.
The 'bootstrap' script uses 'git init'. This patch removes this verbosity.
2025-02-03 Bruno Haible
bootstrap: Remove undesired output.
* top/bootstrap-funclib.sh (prepare_GN
On 2/3/25 15:38, Bruno Haible wrote:
the
default:
break;
lines were a witness that the programmer has spent some thought
regarding the other values.
This is the first I've heard of that style. And the "default: break;"s I
put into quotearg.c are not part of that s
Hi Bruno,
Bruno Haible via Gnulib discussion list writes:
> So, these compilation units in coreutils MUST be compiled with -Wno-error.
>
> This patch achieves that.
>
> Previously we had added -Wno-error only on the gnulib tests. This patch
> adds it also for the source files in lib/.
Thanks, t
Paul Eggert wrote:
> + quotearg: pacify -Wswitch-enum
> + * lib/quotearg.c (quotearg_buffer_restyled): Use switch (+E), and
> + omit default case, to pacify gcc -Wswitch-enum. This is a good
> + way to pacify -Wswitch-enum when we don’t want to enumerate
> + all the enum values
Compiling the newest coreutils from git, in a git checkout with
no '.tarball-version' file, with gcc 14 produces the following errors:
gcc-14 -ftrapv -I. -I./lib -Ilib -I./lib -Isrc -I./src -Werror
-fstrict-flex-arrays -Wall -Warith-conversion -Wbad-function-cast
-Wcast-align=strict -Wdate-ti
This patch fixes a long-standing bug in gnulib-tool: Library-specific
CPPFLAGS and CFLAGS, i.e. libgnu_a_CPPFLAGS and libgnu_a_CFLAGS, would
only apply to object files declared through
lib_SOURCES += foobar.c
but not to object files declared through
AC_LIBOBJ([foobar])
For the latter, the $
Kirill Makurin wrote:
> The installer from https://osdn.net/projects/mingw/ is the same as
> found in https://sourceforge.net/projects/mingw/ (except for possible
> difference in versions) and the Wikipedia article points to the former
> website (mingw.org website is no longer alive). This installe
I tested updated patches and they work for both Msys2 and *MinGW*. For
completeness, I also tried using it from Cygwin and it works as expected.
From: bug-automake-bounces+maiddaisuki=outlook@gnu.org
on behalf of Bruno
Haible via Bug reports for Automake
Se
Hi Bruno,
On Jan 30 00:43, Bruno Haible wrote:
> Hi Corinna,
>
> Corinna Vinschen wrote:
> > > I keep the Cygwin (32-bit) CI, since that is running a fixed release
> > > (3.3.6) —
> > > no risk of regressions caused by Cygwin.
> >
> > We released 3.5.6 with a lot of related patches last Sunday,
The installer from https://osdn.net/projects/mingw/ is the same as found in
https://sourceforge.net/projects/mingw/ (except for possible difference in
versions) and the Wikipedia article points to the former website (mingw.org
website is no longer alive). This installer provides both `mingw-*` (
Kirill Makurin wrote:
> I applied patches and they work for Msys2.
>
> I also tested it with (what I assume is) "Msys-based MinGW"
> (https://osdn.net/projects/mingw/) and it fails. Its `uname -s` reports
> `MINGW32_NT-6.2` and it has `MSYSTEM` set , and it lacks `cygpath`.
> ...
> I explicitly
I applied patches and they work for Msys2.
I also tested it with (what I assume is) "Msys-based MinGW"
(https://osdn.net/projects/mingw/) and it fails. Its `uname -s` reports
`MINGW32_NT-6.2` and it has `MSYSTEM` set , and it lacks `cygpath`.
Should we even distinguish between "original MinGW"
13 matches
Mail list logo
