Bruno Haible writes:
> The other reason is that every package maintainer has their preferred set of
> warnings — that's what the 'manywarnings' module is made for —, but it does
> not make sense for package maintainers to enforce the absence of certain
> warnings on code that 1) they don't mainta
The Gnulib module 'maintainer-makefile' has two bad effects on the packages
that import it. When GNU make is used (i.e. practically all GNU systems):
1) It executes the compilation of files (in lib/, src/, etc.) in the C locale.
Thus, even if the user who builds the program has a preferred languag
On 6/10/21 8:41 AM, Bruno Haible wrote:
The bad effects affect
* the developers who work from a git checkout + all users of the tarball
for packages that include GNUmakefile and maint.mk in their tarballs,
e.g. GNU findutils, GNU guile, GNU gzip, GNU libidn, GNU m4, GNU patch,
G
Paul Eggert wrote:
> As I vaguely recall, that "export LC_ALL = C" was added so that builds
> were reproducible, which is a plus.
People who want reproducible builds can run
LC_ALL make && LC_ALL make check
if they like to. This is no reason to significantly reduce the test suite's
effectiven
> LC_ALL make && LC_ALL make check
I meant: LC_ALL=C make && LC_ALL=C make check
On 6/10/21 10:12 AM, Bruno Haible wrote:
Perhaps we could try to get the best
of both worlds, by changing it to set LC_ALL to an English UTF-8 locale
if available, and the C locale if not.
This still would prevent the GNU m4 test suite from producing a test failure
for the aforementioned m4-1.4.
Paul Eggert wrote:
> How about this idea instead? Have the GNUmakefile code run the 'locale'
> command and include its output in the 'make' output. That way, the
> 'make' transcript would indicate this particular detail of the test
> environment.
It would make sense to have this info in the gen
On 6/10/21 10:34 AM, Bruno Haible wrote:
I think your suggestion should be implemented in Automake's
test suite drivers, not in maint.mk.
Not everybody who uses Gnulib uses Automake. But I take your point that
the 'locale' output is better localized to 'make check', which is
something that co
Paul Eggert wrote:
> For what it's worth I'm more with Bruno on this. For the tests, the cost
> of these warnings outweighs the benefit.
>
> It'd be OK with me to disable the troublesome warnings globally for the
> tests subdirectory, using -Wno-missing-prototypes or whatever.
Thanks for your b
Simon Josefsson wrote:
> Most of my projects have multiple gnulib instances in
> them, which gnulib self-tests does not support.
Yes, this situation is not supported.
> I try to have gnulib tests enabled, but sometimes I disable them because
> having them enabled leads to problems that are too ti
Dmitry V. Levin wrote:
> Unlike many other gcc warnings, -Wmissing-prototypes is especially useful
> because it doesn't report false positives, so I don't see why one may want
> to turn -Wmissing-prototypes off.
Sometimes a function in a test is not used on some platforms. What are the
possible wa
On DragonFly BSD, sigsegv.c uses a 'struct sigcontext *'. This won't change
soon, since DragonFly BSD supports only one architecture: x86_64.
2021-06-07 Bruno Haible
sigsegv: Document context type for DragonFly BSD.
* lib/sigsegv.in.h (stackoverflow_context_t): On DragonFly BS
>> I think there is room for improvements in this field
>
> From what you are telling, the first improvement should be to clarify
> where to report failing tests. Done as follows:
Great! I think this will help, reporters rarely know anything about
the project and just report a build failure, and
13 matches
Mail list logo
