Hey everyone,
Thanks for coming back to this.
As I said, I'm primarily not a fan of having different code paths depending on
build type; that makes debugging harder than necessary.
Just a remark, in theory, you can have the cake and eat it, but afterwards your
plate will be riddled with the cr
Hi Bruno,
On 16.03.23 04:46, Bruno Haible wrote:
Apparently Paul and you have different ways of reading code, which
leads to different measures of "readability". You two could keep
contradicting each other eternally; that's not fruitful.
I don't intend to do that :) Paul seems to be the more exp
Hey Paul,
I think we're in agreement, even though I've been in the situation that the compiler
warning me about unitialized variable usage has saved me a lot of headache – and maybe
that's why I'm more sympathetic to making the compiler happy in such isolated circumstances.
We both would like t
#x27;s sanity's sake - initialize it.
That has no real downside but your feeling that you for some reason did not
stand up to GCC by putting a macro where a =0 would have done.
Sorry to disagree so strongly,
Best,
Marcus
Am 15. März 2023 23:42:49 MEZ schrieb Paul Eggert :
>On 3/15/23 02:41,
Hi Bruno,
thanks for picking this up! And also, about all the background you're giving; that's much
appreciated.
On 14.03.23 22:45, Bruno Haible wrote:
[CCing bug-gettext, since po/Makefile.in.in comes from GNU gettext.]
Thanks :) forwarding a patch is quite an endorsement.
msgmerge: do not
Hi Paul,
Uff, being a newb to this community, I feel really bad about giving my 2ct to roughly the
first thing I read on the mailing list, but:
Let's not do what GNU emacs does.
Having different code when linting and not linting makes bugs that only happen in
non-debug/lint builds impossible
Progress indicators in Makefiles are nearly universally unappreciated, since
they completely break compactness of the build log, and also make output
humanly unparseable if -j>1 is used
Signed-off-by: Marcus Müller
---
build-aux/po/Makefile.in.in | 2 +-
1 file changed, 1 insertion(+)
ng
that GCC is *that* buggy here.
Cheers,
Marcus
On 14.03.23 17:50, Pádraig Brady wrote:
On 14/03/2023 13:55, Marcus Müller wrote:
Dear Gnulib community,
On Linux, x86_64, Fedora 37, ran, on today's coreutils' HEAD (e68b15), which
submodule-includes gnulib f17d3977:
CFLAGS=-Wn
Hi Bruna,
thanks for answering,
On 14.03.23 17:41, Bruno Haible wrote:
The build only fails because coreutils' configure.ac turns warnings into
errors by default in some situation.
Obviously, I agree with this on the deprecated functionality warning, but the string
method argument overflow w
Dear Gnulib community,
On Linux, x86_64, Fedora 37, ran, on today's coreutils' HEAD (e68b15), which
submodule-includes gnulib f17d3977:
CFLAGS=-Wno-deprecated-declarations ./configure
(as that CFLAGS is necessary, otherwise sha will fail to build due to using
deprecated functionality; no big
10 matches
Mail list logo
