https://sourceware.org/bugzilla/show_bug.cgi?id=31881
--- Comment #22 from Rostislav Krasny <rostiprodev at gmail dot com> --- (In reply to Nick Clifton from comment #21) > > Ok. Then what is the reason of generating VERSION_DATE from ChangeLog.git or > > from the current date? > > These methods are meant to handle the case where the sources are not in a > clone of the repository and not from a release tarball. Besides the snapshots mentioned below are there any other cases of not release tarballs? > > If this is done in case of a snapshot version, how > > that snapshot version is made? Isn't it a regular tarball created by the > > src-release.sh script sometime between official releases? > > Yes - in fact there is now a script on Sourceware that creates snapshots > each time a commit is applied to the repository. I suppose that the script that creates the snapshot tarballs has an access to the Git repository of binutils-gdb project? If it has, could that script generate the bfd/version.h file with the value of the BFD_VERSION_DATE taken from the Git repository? Then any snapshot will have the bfd/version.h already generated and the configure script will not have to do it again without any access to the Git repository. In other words let's generate the bfd/version.h during creation of any tarball (snapshot, release, whatever) or during a direct build from the Git repository only. Build from any tarball should NEVER deal with this task and should get the bfd/version.h already located in the tarball. It will make the shell code that finds the value of BFD_VERSION_DATE much simpler because it will find it in the Git repo only and not in other less reliable places like $srcdir/ChangeLog.git -- You are receiving this mail because: You are on the CC list for the bug.
