maya%netbsd.org@localhost writes:
> +.if exists(${LOCALBASE}/gcc6/bin/gcc)
> +GCC_REQD+= 6.0
> +GFORTRAN_VERSION= 6
I think we should be heading to deterministic behavior, where the
compiler version (for all except bootstrapping toolchains) is set by a
variable explicitly by the user, or from a per-platform default. Your
suggestion, I think, would result in binaries with mixed compilers (main
and various libs) depending on build ordering and if a compiler got
installed. And certainly packages built with different compilers
depending on build ordering.
Agreed that locking C/fortan together seems like a good idea.
As I see it the debate is between:
A) Force 4.8ish or some particular higher version for all C++, and
hope that's better than what we have now
B) Define a version, and fail packages that need something newer.
A is easy, but not entirely sound. B will result in not having C++14
packages if you pick 4.8, and I think that will lead to "when using gcc,
build gcc 6 if not native and then use it for everything". That
certainly hurts a bit to build it, but I'm not sure it's really a big
problem in the end. The underlying reality is that
compilers/sublanguages have been changing/being-used faster than
compilers change due to OS update cycles.
Further, we probably should separate
version that should be used in general (PKGSRC_GCC_VERSION?)
and
min version this package needs (GCC_REQD)
conceptually, as well as unlink GCC_REQD's behavior. The point is that
it declares the min version. Whether we find a new one or fail is then
a choice.
Attachment:
signature.asc
Description: PGP signature