Re: [PATCH] config.mak.dev: fix typo when enabling -Wpedantic

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

 



On Sat, Jul 06, 2024 at 02:31:43AM -0400, Jeff King wrote:
> > Causing our Makefile (when invoked with DEVELOPER=1, and a sufficiently
> > recent compiler version) to barf:
> >
> >     $ make DEVELOPER=1
> >     config.mak.dev:13: extraneous text after 'ifneq' directive
> >     [...]
> >
> > Correctly combine the results of the two "$(filter ...)" operations by
> > using "$(or ...)", not "$or".
>
> ...why don't I see this error? Based on the bug, I think that we'll
> always pass -Wpedantic, even for old compilers (because our weird "or"
> will never be the empty string).
>
> So I could understand if the symptom was then that when you have an old
> compiler, we feed it -Wpedantic and it complains (though the fact that
> nobody noticed such a behavior makes me wonder if we even care about
> such old compilers now?).
>
> But why does make complain here only sometimes? Does it depend on the
> version of make?

It seems to depend on the version of make you're using. On my system,
'make' is GNU Make 4.4.90, which has the more restrictive checks around
the recipe prefix in nested conditionals.

With that version (and the pre-image of this commit), I get:

    $ make -v | head -1 && make DEVELOPER=1 2>&1 | head -1
    GNU Make 4.4.90
    config.mak.dev:13: extraneous text after 'ifneq' directive

, but with /usr/bin/make (which on my machine is GNU Make 4.3), I
instead get:

    $ /usr/bin/make -v | head -1 && /usr/bin/make DEVELOPER=1 2>&1 | head -1
    GNU Make 4.3
    GIT_VERSION = 2.45.2.746.g06e570c0df

I think other factors that might be at play here are (a) whether or not
you have DEVOPTS=no-pedantic (in which case you'd bypass this entire
part of config.mak.dev), and (b) whether or not you have a sufficiently
recent compiler.

It is tempting to just want to rip out support for older compilers, but
given that ebd2e4a13a (Makefile: restrict -Wpedantic and
-Wno-pedantic-ms-format better, 2021-09-28) is only three years old, I
imagine that some builders may still want support for older / pre-GCC 4
compilers.

Thanks,
Taylor




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux