Hi!
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)?
Jakub
