bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: another manywarnings failure


From: Jim Meyering
Subject: Re: another manywarnings failure
Date: Thu, 06 Sep 2012 17:11:46 +0200

Jim Meyering wrote:
...
> Yes, it looks like if we're using both of those, we'll have to
> add code to reject -Wuninitialized (maybe with a warning?) when
> configuring without -O.
...
> [here's simple PoC, i.e., it doesn't know about -O0,
>  but you get the idea ]
>
> W = -Wuninitialized -Werror
> CFLAGS = -O
>
> ifneq (,$(findstring -Wuninitialized,$(W)))
>   ifneq (,$(findstring -Werror,$(W)))
>     ifneq (,$(findstring -O,$(CFLAGS)))
>       W := $(subst -Wuninitialized,,$(W))
>     endif
>   endif
> endif
>
> all:
>       @echo $(W)

Not quite.  The innermost test was reversed: s/ifneq/ifeq/:

# With -O in $(CFLAGS) and both -Wuninitialized and -Werror in $(W),
# remove -Wuninitialized from $(W).
ifneq (,$(findstring -Wuninitialized,$(W)))
  ifneq (,$(findstring -Werror,$(W)))
    ifeq (,$(findstring -O,$(CFLAGS)))
      W := $(subst -Wuninitialized,,$(W))
    endif
  endif
endif

Also, cfg.mk is project-specific.  This is general enough that
a shared file like maint.mk would be a better home for it.
On the other hand, if you want to change the .m4 file, that
would probably be even better, from a locality standpoint.
Oh... and then there's the issue of the multiple WARN_CFLAGS
variables.  coreutils has these three:

  GNULIB_TEST_WARN_CFLAGS
  GNULIB_WARN_CFLAGS
  WARN_CFLAGS

Hmm... with that realization, and knowing that those variable names
are not standardized, the makefile-based approach looks even less
interesting.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]