Re: CVS commit: pkgsrc/geography/gama

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

Moving to tech-pkg, because this is important.

Jonathan Perkin <jperkin%mnx.io@localhost> writes:

> * On 2023-07-11 at 13:16 BST, Thomas Klausner wrote:
>
>>On Mon, Jul 10, 2023 at 03:01:23PM +0000, nia wrote:
>>> On Mon, Jul 10, 2023 at 09:22:37AM -0400, Greg Troxel wrote:
>>> > "Nia Alarie" <nia%netbsd.org@localhost> writes:
>>> >
>>> > > Modified Files:
>>> > > 	pkgsrc/geography/gama: Makefile
>>> > >
>>> > > Log Message:
>>> > > gama: Sync compiler requirements with reality.
>>> >
>>> > > @@ -11,10 +11,13 @@ HOMEPAGE=	https://www.gnu.org/s/gama/
>>> > >  COMMENT=	Geodetic network adjustment (surveying)
>>> > >  LICENSE=	gnu-gpl-v2 # or later
>>> > >
>>> > > -USE_LANGUAGES=	c c++11
>>> > > +USE_LANGUAGES=	c c++
>>> >
>>> > Why is c++11 changed to c++, rather than to c++14?
>>>
>>> USE_LANGUAGES is for forcing a -std=cXX value through the wrappers,
>>> gama already uses -std=c++14 upstream.
>>
>>If we know that upstream really wants c++14, I think we should add it
>>in USE_LANGUAGES. What's the disadvantage?
>
> The disadvantage is that you are now tied in to updating USE_LANGUAGES
> every time a package changes the standard it targets.
>
> I agree with nia that it should be "c++" unless we absolutely need to
> override it (which is effectively an upstream bug).

jperkin: Do you think we should also drop 'c99' from USE_LANGUAGES and
just have C?



First, a meta point:

  We have been using USE_LANGUAGES as the language -- where c++14 and
  c++17 are different languages -- for a long time.  nia edited the guide
  to change the rules, without a discussion (that anybody on pmc noticed).
  This is not ok, and we need to revert the guide change first, and stop
  edits based on it.  This point is completely orthogonal to the technical
  discussion below.

As for the technical content, I think a lot of things are pretty clear:

  The status quo wasn't entirely right.

  C++(03), C++11, C++14, C++17 etc. are actually different languages
  within the C++ language family.

  The same thing is true with C, C99 and newer C, except that the C
  world is saner and the vast majority builds with c99.

  Given the rate of new languages, this problem isn't going away.

  When you need to compile a C++14 program, you need a compiler that
  accepts the C++14 language.   A "C++ compiler" is in general not
  sufficient.

  A package might possibly need to use multiple C++ language family
  members at different times.

  Programs that are written in a particular language from the C++ family
  need to pass --std=c++NN flags; it's buggy to assume the compiler
  defaults to what is wanted.

  We have to somehow mark a package to cause an adequate compiler to be
  used.

  The compiler in use might be from the gcc family, or clang, or
  something else.

and therefore, more or less

  The adding of --std= in the wrappers should be decoupled from
  USE_LANGUAGES.  Something like WRAPPER_CXX=c++17 (bad name), which
  tells the wrappers to add to all cxx invocations the --std=c++17 that
  the package should have done itself.

  USE_LANGUAGES should continue to contain the particular member in a
  language family.  Yes it needs to be updated, but this should be very
  clear in upstream NEWS, just like adding rust, changing from c to c++,
  requiring cmake, or any of a large class of other significant
  changes.   Plus, it's not hard to update it, and nothing terrible
  happens if you don't.

  We should somehow make e.g. USE_LANGUAGES=c++17 lead to GCC_REQD=foo
  if the compiler is gcc, and have similar mechanisms architecturally
  for other compilers.  It is not reasonable to open-code the same
  information in tons of packages -- even if it is the status quo.

  It should be a error/warning to set WRAPPER_CXX to a value that is not
  in USE_LANGUAGES.

  The wrappers should error out if --std=foo is passed to a compiler if
  foo is not in USE_LANGUAGES.


This is a very minor change from longstanding practice: adding a
GCC_REQD automatically based on USE_LANGUAGES.  My impression is that
~everyone thinks this is a good change but there just have been enough
round tuits.  My impression is that ~everyone thinks that setting
GCC_REQD based on language version is at least partially kludgy.