Re: A better method to require compiler features

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

nia <nia%NetBSD.org@localhost> writes:

[Thank your for reverting.]

> In light of recent discussions, I would like to add a
> new variable to the pkgsrc infrastructure. It could
> will be used in the following ways:
>
> USE_CXX_FEATURES+=	c++14
>
> To require at least GCC 7, but not NetBSD gcc 7:
>
> USE_CXX_FEATURES+=	filesystem
>
> To require at least GCC 4.9:
>
> USE_CXX_FEATURES+=	regex
>
> This would set the appropriate GCC_REQD without intefering
> with the compiler wrappers.

This seems like a great approach.  Splitting the features into
fine-grained things addresses the issue of "need C++NN implies gcc foo"
not being quite right.  And critically for me, it avoids open-coding of
gcc versions in every package, which while a longstanding workaround, is
icky, hard to deal with, and fails to deal with other compilers.

This says "GCC_REQD", but pkgsrc supports multiple compilers.  I'm fine
with "ensure that a high enough version of the compiler in use is
present, architecturally" along with "for some compilers (maybe even all
but gcc), this is not currently implemented".  I think it's important to
have an architectural path forward, even if we don't expect it to
happen.  (Because only clang matters, and that tends not to be so
afflicted with these issues, but that day will come especially if we try
to support FreeBSD more.)

> In addition, users would be able to decide how missing
> compiler features are handled.
>
> setting in /etc/mk.conf:
>
> SKIP_CXX_REQUIREMENTS=	yes
>
> would skip building any packages where the current compiler is
> "good enough". This is helpful for situations where vendored
> or specifically modified toolchains are required, and upstream
> GCC is not suitable.

I don't understand this.  Do you mean that if yes, the contents of
USE_CXX_FEATURES is ignored?  If so, maybe IGNORE_CXX_FEATURES, but
really the important thing is to be clear on it.

Or do you mean "if the package would need a new compiler, then instead
fail the build"?


There is another problem, which I think is entirely separable (until I
saw this proposal I wans't so sure).  That is that it's not a great
approach to build a tree and require 3 different built gcc versions.
Once you are going to build one, you, as far as I can tell, might as
well build a pretty recent one, and use that any time you need better
than base.   E.g. on netbsd-9, just use gcc10 and skip ever building 8
and 9.  Or maybe higher than 10.   But I think this is orthogonal to the
features proposal you have made.