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 4.3.5 Status Report (2010-05-22)

On Tue, Feb 1, 2011 at 5:31 AM, Richard Guenther
<> wrote:
> On Mon, Jan 31, 2011 at 6:56 PM, Joseph S. Myers
> <> wrote:
>> On Mon, 31 Jan 2011, NightStrike wrote:
>>> On Mon, Jan 31, 2011 at 7:51 AM, Richard Guenther
>>> <> wrote:
>>> > On Mon, Jan 31, 2011 at 3:43 AM, Dongsheng Song
>>> > <> 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.

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