Re: proposal for setting minimum upgraded compiler version

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

Jason Bacon <jtocino%gmx.com@localhost> writes:

> On 7/13/23 11:48, Greg Troxel wrote:
>> This is meant to be complementary to the USE_CXX_FEATURES proposal, and
>> almost entirely separable from it.  It tries to distill some previous
>> comments.
>>
>> Currently, we can end up with GCC_REQD of various values.  The same will
>> happen with USE_CXX_FEATURES, via the mapping from features to version.
>> The same could in theory happen with clang or other compilers.
>>
>> This results in building multiple gcc versions which
>>
>>    is wasteful of CPU time, disk writes, space etc
>>
>>    makes the "different libstdc++" problem worse
>>
>>    doesn't seem to have any real benefit.
>>
>> The proposal (which is drafty) is
>>
>>    define MIN_UPGRADED_GCC_VERSION.   This can be set in platform.mk, and
>>    if not will be a default in some gcc.mk.  Or it can be set by the
>>    user.
>>
>>    Allow defining MIN_UPGRADED_FOO_VERSION for other compilers, even if
>>    not implemented.
>>
>>    Whenever base gcc is not good enough, if MIN_UPGRADED_GCC_VERSION is
>>    >= the version that is required, use MIN_UPGRADED_GCC_VERSION instead.
>>    Similarly for other compilers, even if not implemented.
>>
>>    Use MIN_UPGRADED_GCC_VERSION when building gfortran etc.
>>
>> and that's the entire proposal.  It does not preclude other proposals,
>> like bootstrap a compiler and use it, or use MIN_UPGRADED_GCC_VERSION
>> for everything that you don't need to build gcc.  The point is that the
>> proposal is small with limited consequences and I think we can probably
>> agree on it and do it, and make progress.
>>
>> A straw value for MIN_UPGRADED_GCC_VERSION right now is 10, based on my
>> netbsd-9 box having gcc 7, 8, 9 and 10 all built.  I have no objection
>> to a higher value, except that it has to build and I don't know about
>> that.  I have no objection to using different values different places;
>> picking 12 in general and dropping it to 10 on systems that won't build
>> 12 might be reasonable.  We don't have to agree on the values to agree
>> on this being an ok approach.
>
> I'd use the highest stable GCC that builds with the Yum compiler in
> supported RHEL versions.  I don't know what that is currently since I
> don't have a RHEL 7 system running right now, just Alma 8.  One of the
> active HPC / scientific computing developers might know.

Since you only commented on the specific choice, it sounds like you are
in favor of the rest.

That sounds perhaps ok, but it's going to have to be situational, and it
might end up being low for ancient RHEL.  We don't have a clear idea of
supported RHEL and the basic issue is that old RHEL is unreasonabley
old.  RHEL doesn't seem to be sending checks to TNF to pay for support
labor :-(

But, my concept includes a general default, and a way for trailing edge
systems (NetBSD 8, RHEL from 2013) to be lower.   I just don't want to
be old for everybody because people want to use old RHEL.

> We'll still need a way to exempt the gcc package itself and all of its
> dependencies, the list of which can change with minor updates.

No, we don't.  That's outside the scope of my proposal, which is only
effective *if* a compiler other than base is forced.

Or maybe we do, but it's a separate discussion.