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: NightStrike <nightstrike at gmail dot com>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery 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 08:24:17 -0500
- 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> <AANLkTimNTVb4-rOc+7eSS9Vz_c-UADvCG1BXxgsu1F6a@mail.gmail.com>
On Tue, Feb 1, 2011 at 5:31 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> 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.
>
I can't find it right now, but I read something recently about using
hooks to put revision numbers inside source controlled files.