Re: default C versions

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

Havard Eidnes <he%NetBSD.org@localhost> writes:

> Hmm, tangentially related, since I do pkgsrc bulk builds for
> NetBSD/macppc 8.0, I find quite a bit of issues of this sort:
>
> /usr/pkgsrc/textproc/syntax-highlighting/work/syntax-highlighting-5.98.0/src/indexer/katehighlightingindexer.cpp:179:42: error: 'as_const' is not a member of 'std'
>              for (const auto &styleName : std::as_const(unusedNames)) {
>                                           ^
> "std::as_const" is according to
>
>   https://en.cppreference.com/w/cpp/utility/as_const
>
> a c++17 construct, and obviously the C++ compiler in 8.0 (5.5.0)
> does at least not by default support c++17.
>
> I'm wondering a bit about what to do in this case.
>
> I could add a USE_LANGUAGES+=c++17 (or gnu++17 if the package uses
> alloca()) to the package.  Arguably, that would ba a correct
> declaration given the use of the above construct,

It is entirely correct; if the code is C++17 then it needs to be in
USE_LANGUAGES.  IMHO it's a bug that compiling that code with a compiler
that wasn't passed --std=c++17 or higher works.  Also, pkgsrc should be
passing explicit --std based on USE_LANGUAGES, and I think it does.

There is no USE_LANGUAGES now, which defaults to C, but includes kde's
Makefile.common which adds c++.  And cmake unhelpfully omits build
lines.

> But it's far from
> certain that it will fix the build on this platform, as this does
> nothing to influence which C++ compiler is used.

True, but that's a lack of a feature in pkgsrc.  It's not a reason to
avoid fixing USE_LANGUAGES errors.

> However, with C++ it's even more fraught with danger than with C to
> mix use of different C++ compilers, since the ABI has evidently
> changed over time, and sometimes in non-backward-compatible ways, if
> I've understood correctly.

It is fraught and there used to be problems, but these days while
technically unsound I am not perceiving reports of real problems.

> So, what to do?  Nothing or add a USE_LANGUAGES+= setting?

multiple things to do:

  Stop using NetBSD 8.  Seriously, it's past due to upgrade everything
  running 8 to 9.  I personally have no 8 systems, and I don't worry
  about things not working on 8.

  Add USE_LANGUAGES to the languages used by upstream.  If upstream uses
  a language and doesn't document it, file an upstream bug.

  Someone(tm) should figure out if c++ being the highest c++ in
  USE_LANGUAGES leads to --std=c++03 and if not fix that and test for
  problems.  Finding incorrect USE_LANGUAGES is not a problem; the point
  is that failing to declare a used language should lead to failure even
  if one's compiler would compile it *without an explicit --std*.

  Someone should prototype adding GCC_REQD automatically based on
  USE_LANGUAGES, if PKGSRC_COMPILER contains (NB: not "is equal to")
  gcc, and see how that works.  If it's as good as hand-sprinkled
  GCC_REQD we should start removing the hand-sprinkled ones, which are a
  kludge because it doesn't work automatically.

  Prototype and test integration of Jason's
  use-newer-for-all-but-bootstrap code.  By integrate I mean enough that
  a default pbulk will use it, on platforms that need it.

  Prototype and test integration of
  build-bootstrap-separate-prefix-then-use-it code.  By integrate I mean
  enough that a default pbulk will use it, on platforms that need it.