This is the mail archive of the
mailing list for the GCC project.
Towards removal of gcc/DATESTAMP
- From: Jakub Jelinek <jakub at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>, "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>, Jonathan Wakely <jwakely at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 14 Jan 2020 16:52:12 +0100
- Subject: Towards removal of gcc/DATESTAMP
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
The following command prints the same string as DATESTAMP file
contains in all gcc-7 and later based branches I've tried so far (and nothing when
e.g. invoked from within svn checkout).
o=$(git config --get gcc-config.upstream); test -z "$o" && o=origin; r=$(cat BASE-VER | cut -d. -f 1); b=; if git rev-parse --verify --quiet $o/releases/gcc-$r >/dev/null; then b=origin/releases/gcc-$r; elif git rev-parse --verify --quiet $o/releases/gcc-9 >/dev/null; then b=$o/master; fi; test -n "$b" && TZ=UTC LC_ALL=C git log --date=iso -1 $(git merge-base HEAD $b) | sed -n 's/^Date:[[:blank:]]*//p' | sed 's/ .*$//;s/-//g'
I haven't bothered with the bumping at 00:16 UTC, the script assumes bump
on 00:00 UTC instead.
Do we want to replace DATESTAMP bumping with something like that?
There are several issues that need to be figured out:
1) some trees will not be git repositories, e.g. release tarballs, snapshot
tarballs or e.g. vendor gcc tarball snapshots; for release
tarballs/snapshots, we could arrange for gcc_release to create
gcc/DATESTAMP file that way and have some script e.g. for vendors to
use that would do the same; gcc/Makefile.in then could use
gcc/DATESTAMP if it is present, fallback to git command above (perhaps
made more portable if needed) and fail if neither works?
2) in gcc/Makefile.in, e.g. version.o depends on DATESTAMP file and the
rebuild happens when the timestamp on that file changes; should we
e.g. create gcc/DATESTAMP file in the build directory with some
move-if-change hacks around and let version.o depend on a goal that
will do that and on the build directory gcc/DATESTAMP?
3) should we handle gcc/REVISION stuff similarly (and use what
gcc-descr alias does without that alias) for that commit, perhaps
with --full or maybe just with somewhat smaller --abbrev= (say 20 rather
than 40 chars)?