Re: dealing with inevitable warnings from new compilers on old code

[Greg Troxel <gdt%lexort.com@localhost>]

"Greg A. Woods" <woods%planix.ca@localhost> writes:

> I'm going to try moving this to tech-pkg for further discussion

You didn't; you cross posted....

> Now that USE_LANGUAGES is officially(?) deprecated

It is not, but what USE_LANGUAGES used to mean is now separated into
multiple pieces, and things are vastly better than they used to be.

USE_LANGUAGES defines language families, like c or c++.

USE_C_FEATURES/USE_CXX_FEATURES have tokens that can represent either
language family members (e.g. c++17) or specific language features (that
are often formally part of a family member, but are separated), like
filesystem.

FORCE_{C,CXX}_STD adds --std=foo via the wrappers.  As I read the
documentation and the code, this is independent of requiring a compiler
that needs that.  That reading matches my inuition about how this ought
to be.  So a C++17 program that fails to set --std=c++17 needs:

USE_LANGUAGES=		c++
USE_CXX_FEATURES=	c++17
FORCE_CXX_STD=		c++17

> FORCE_C_STD seems the only viable choice, especially since
> USE_CC_FEATURES is orthogonal or even opposite in purpose to this
> particular issue.

I am not following your logic.

If a program is written in some particular C language family member (c11
say) and it does not probe for --std=c11 at configure time and pass
--std=c11 at compile time, then it is buggy.   FORCE_C_STD=c11 is a
pkgsrc workaround to cause --std=c11 to be passed to the compiler, and
no more.

If a program has code that triggers warnings when compiled with a
non-buggy compiler that supports the documented language family member
and perhaps FORCE_C_STD, and also sets -Werror, that's a separate issue,
but it really isn't about the language family.

While a lot of this is hard to fix -- upstream code that isn't quite
right, overzealous warnings, and each new gcc version behaving
differently -- I feel it is pretty straightforward to understand.