This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC version bikeshedding
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Andreas Schwab <schwab at linux-m68k dot org>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Jakub Jelinek <jakub at redhat dot com>, gcc at gcc dot gnu dot org
- Date: Tue, 22 Jul 2014 08:44:41 +0100
- Subject: Re: GCC version bikeshedding
- Authentication-results: sourceware.org; auth=none
- References: <20140720165506 dot GT3003 at laptop dot redhat dot com> <7564e4f5-8030-4a23-8b0b-b1262265a349 at email dot android dot com> <87ha2ao6hj dot fsf at talisman dot default> <87zjg232tu dot fsf at igel dot home>
Andreas Schwab <schwab@linux-m68k.org> writes:
> Richard Sandiford <rdsandiford@googlemail.com> writes:
>> Does that mean that __GNUC_MINOR__ is going to become the patchlevel?
>> Or is __GNUC_MINOR__ going to be 0, with 5.x.y setting __GNUC_PATCHLEVEL__
>> to x? If the latter, what happens to y?
>
> Why is there any need to redefine these macros?
But which of the two options is the one that redefines the macros?
AIUI the suggestion is that releases from the next branch
would be 5.0.0, 5.1.0, 5.2.0, etc., rather than 5.0.0, 5.0.1, 5.0.2, ....
So if x.y.z is __GNU__.__GNU_MINOR__.__GNU_PATCHLEVEL__ then the positions
in the number stay the same but the meanings of __GNU_MINOR__ and
__GNU_PATCHLEVEL__ change. (__GNU_PATCHLEVEL__ becomes a vendor-specific
thing and would always be 0 in FSF releases.) If x.y.0 is
__GNU__.__GNU_PATCHLEVEL__ then the meanings stay the same but the
positions in the number change.
It seems odd for the official version to always be x.y.0. But I suppose
we can't make it x.y because that would break configure scripts. So why
not just stick to the current scheme and have 5.0.0, 5.0.1, 5.0.2 etc.?
Richard