https://sourceware.org/bugzilla/show_bug.cgi?id=31881
--- Comment #20 from Rostislav Krasny <rostiprodev at gmail dot com> ---
(In reply to Nick Clifton from comment #19)
> > If any source tarball created by the src-release.sh it already contains
> > the generated version.h file with properly generated VERSION_DATE from
> > the last commit in the Git repo. I think in case of source tarball the
> > configure script should not try to generate the version.h again because
> > it already exist.
>
> Yes - this is what should happen.
Ok. Then what is the reason of generating VERSION_DATE from ChangeLog.git or
from the current date? 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?
I just thought only three cases of the configure script being running are
possible: [1] building directly from the Git repo, [2] making a tarball
(release/snapshot/whatever) by the src-release.sh script from the Git repo, and
[3] building (release/snapshot/whatever) from a tarball previously created in
case 2. Only in cases 1 and 2 the configure script needs to generate version.h
and the $VERSION_DATE value, and in case 3 it should do nothing about version.h
and $VERSION_DATE because version.h is already existing in the tarball. Right?
> > This line in your patch assumes the date could always be found in
> > the very first line of the change log file:
> >
> > VERSION_DATE=$(head -1 $srcdir/ChangeLog.git | cut -b 1-10 | sed -e s/-//g)
>
> True - the assumption might be true most of the time, but you are
> correct - the code should not rely upon it.
>
> > What do you think about changing that code into the following one?
> >
> > VERSION_DATE=$(grep -m 1 -Po '^\d{4}-\d{2}-\d{2}(?=\s+)'
> > $srcdir/ChangeLog.git | sed s/-//g)
>
> Much better. The uploaded new patch includes this change.
Ok
> > I also don't see the ChangeLog.git file anywhere in the Git repo
> > of binutils. Did you mean ChangeLog file?
>
> No - the ChangeLog.git file is created as part of the binutils
> release process, so it should always be present in release tarballs,
> but absent from the git repository.
Ok
> I also found that the "git rev-parse --is-inside-work-tree" does not work
> as desired. If run outside of a repository it returns a fatal error and
> stops the rest of the scriptlet from running. So I have replaced it with
> a test for the .git directory at the top level of the source tree. Which
> I think should always work.
Does the configure script have 'set -e' somewhere? I didn't find it. Otherwise
why the configure script stops in this case?
--
You are receiving this mail because:
You are on the CC list for the bug.
