This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 4.3.5 Status Report (2010-05-22)
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: NightStrike <nightstrike at gmail dot com>, Dongsheng Song <dongsheng dot song at gmail dot com>, Gerald Pfeifer <gerald at pfeifer dot com>, gcc at gcc dot gnu dot org
- Date: Tue, 1 Feb 2011 11:31:55 +0100
- Subject: Re: GCC 4.3.5 Status Report (2010-05-22)
- References: <alpine.LNX.2.00.1005222256320.1429@zhemvz.fhfr.qr> <alpine.LSU.1.99.1005232108210.26362@acrux.dbai.tuwien.ac.at> <AANLkTikwR2VZuowxH4ijoHghs2qIdaTiehYzu9UF2_R1@mail.gmail.com> <AANLkTi=N-x87fDAD3uzR6Ady--k7Gtj48TgxwukRBA45@mail.gmail.com> <alpine.LNX.2.00.1101302252110.14698@gerinyyl.fvgr> <AANLkTinBdPUZ2F88Eo2dFjC_kRXycUrmWni0t__KwPhX@mail.gmail.com> <AANLkTika1RB7qMcjbB9FLSHpU-hsgZBOtUei2H7=-PYw@mail.gmail.com> <AANLkTi=R6pa3JBjSDf_=WoZEwXB6he_1BuwXCaZL_Cuc@mail.gmail.com> <Pine.LNX.4.64.1101311753400.4363@digraph.polyomino.org.uk>
On Mon, Jan 31, 2011 at 6:56 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Mon, 31 Jan 2011, NightStrike wrote:
>
>> On Mon, Jan 31, 2011 at 7:51 AM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>> > On Mon, Jan 31, 2011 at 3:43 AM, Dongsheng Song
>> > <dongsheng.song@gmail.com> wrote:
>> >> It's very simple (only for trunk, although it maybe more useful for
>> >> branches):
>> >
>> > Or simply put Last-Changed-Date into DATESTAMP, not the
>> > current date.
>>
>> This has other benefits as well, since it means that the date in the
>> gcc version string becomes the date of the last actual revision,
>> instead of the date that the datestamp change is committed.
>
> Not in the case where you have no datestamp changes for a month, say, then
> some other change is committed, but a new datestamp change hasn't yet been
> committed after that other change; then you have, for a limited period, a
> compiler with a datestamp value long before the last commit. ?(That's the
> main case I can think of for not making snapshots if only DATESTAMP has
> changed, rather than the simpler approach of omitting some DATESTAMP
> updates and not making snapshots if nothing at all has changed.)
The DATESTAMP change could also be in a post-commit hook (doing
nothing if the date didn't change, of course). No idea whether this
is technically possible of course.
Richard.