This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC version bikeshedding

Andreas Schwab <> writes:
> Richard Sandiford <> 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.?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]