Fix up CXXSTD support, added in r345708

[ngie]

Summary

r345708 worked for the base system, but unfortunately, caused a lot of
disruption for third-party packages that relied on C++, since bsd.sys.mk is
used by applications outside the base system. The defaults picked didn't match
the compiler's defaults and broke some builds that didn't specify a standard,
as well as some that overrode the value by setting -std=gnu++14 (for
example) manually.

This change takes a more relaxed approach to appending -std=${CXXSTD} to
CXXFLAGS, by only doing so when the value is specified, as opposed to
overriding the standard set by an end-user. This avoids the need for having
to bake NOP default into bsd.sys.mk for supported compiler-toolchain
versions.

In order to make this change possible, add CXXSTD to Makefile snippets which
relied on the default value (c++11) added in r345708. For those Makefile
snippets that allowed the end-user to override the standard, make it default
to the target standard used prior to r345708 to match the behavior from
before the change.

MFC after: 2 weeks
MFC with: r345708
Reported by: jbeich

Test Plan

make tinderbox

[jtl]

lib/libc++/Makefile

79

For all of these libraries, what is the rationale for switching from = to ?=?

share/mk/bsd.sys.mk

28

Is there value in keeping the old check as well? (i.e. ${COMPILER_FEATURES:Mc++11} && !empty(CXXSTD))

(I wonder if it would cause problems if the C++ standard version got added to the build of a C file in a library with mixed C and C++ code.)

[ngie]

lib/libc++/Makefile

79

Apologies. The reasoning is buried in the proposed commit message:

For those Makefile snippets that allowed the end-user to override the standard,
make it default to the target standard used prior to r345708 to match the behavior
from before the change.

share/mk/bsd.sys.mk

28

Is there value in keeping the old check as well? (i.e. ${COMPILER_FEATURES:Mc++11} && !empty(CXXSTD))

No. I don't want this variable to be set based on whether or not the compiler is deemed to be C++11 capable, because it's a very broad brushstroke to apply to everything that relies on bsd.sys.mk, especially because the list in bsd.compiler.mk is incomplete (icc, etc).

(I wonder if it would cause problems if the C++ standard version got added to the build of a C file in a library with mixed C and C++ code.)

It won't cause problems with CSTD values applied to C++ objects, since CXXSTD gets applied later on:

$ make CXXSTD=c++11 -VCFLAGS -VCXXFLAGS
-O2 -pipe -I/home/ngie/svn/freebsd/base/head/lib/libpmc   -g  -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member  -Qunused-arguments 
-O2 -pipe -I/home/ngie/svn/freebsd/base/head/lib/libpmc -g -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Qunused-arguments  -g -std=c++11 -Wno-c++11-extensions 
$ make CXXSTD=c++11 -V'${CFLAGS:M-std=*}' -V'${CXXFLAGS:M-std=*}'
-std=gnu99
-std=c++11

CXXSTD overrides CSTD when both are present, as seen with lib/libpmc.

[emaste]

lib/libc++/Makefile

79

I think this (whole) change is fine, but ISTM that it'd be easier to follow if done as two separate commits. Is it OK to commit just the ?= change first?

[ngie]

lib/libc++/Makefile

79

I'll do that :).

[emaste]

I think this is good

[ngie]

Committed as rS346574 and rS346576.