Add git revision to version information

[benruijl]

When building FORM from a git repository, add the current commit id to the version information.

[tueda]

Actually that would be very nice, but implementing such things in Makefile would be tricky, especially if we want to keep DATE option of make (maybe we can just discard it). A tarball generated by make dist keeps the version date as the last commit date if available. You may be interested in the usage of gendate.sh in https://github.com/tueda/homebrew-loops/blob/master/form.rb.

[tueda]

Here I list the problems to be resolved and describe related information.

What is the preferred format of the version information?

The current format in the FORM outputs is like

ParFORM 4.1 (May  9 2016) 64-bits 1023 workers   Run: Tue May 10 14:27:29 2016

which is fit in 79 characters. (I ignore BETA versions for now.) We may put the git revision of the last commit (say, the first 8 characters), or the date of the last commit, or the both. The date is more human-readable than the git revision, while the git revision is completely unique. But putting both the revision and the date makes the header line longer and it may not be fit in 79 characters. Do we want to remove some characters like 64-bits? Or do we want to allow more than 79 characters and/or 1 line?

Perhaps, we would think about the last lines of the outputs, too. See also #91, which introduces extra lines at the end when -T option is used.

How do we update the version information?

It is nice if the version information is automatically updated when one checks out a revision/branch or modifies the source code (giving a dirty suffix), and only the parts affected by the change are rebuilt. The version information is referred in configure.ac (when autoreconf is executed) and startup.c. manualdate.tex and devrefdate.tex in the documents also use the date information, which is for now forcely updated. Such automatic updates must be embedded in the Autotools build system. On the other hand, one may want to work without the build system/git repository; copying source files from the repository to his/her own directory and building binaries with his/her own Makefiles. We need some fallbacks for such cases.

Currently, one may change the date version in the FORM outputs as follows:

• Manually modify DATE variable in make, for example

make DATE='May  9 2016'

which is referred in compiling startup.c. One needs to delete object files *-startup.o for updates.

• Tarballs generated by make dist.

When tarballs are generated from a git repository, the last commit date is recorded in sources/production-date.h (and also in manualdate.tex and devrefdate.tex for the document). The existence of this file is checked by configure, to make config.h include production-date.h. So it is enough to type the following commands for building executables with the last commit date:

./configure
make

• Manually update production-date.h.

This may be done by

automake -i
scripts/gendate.sh -c -o sources/production-date.h
./configure
make

Note that gendate.sh should be executed before configure because the configure script checks if production-date.h exists, while one can update production-date.h by gendate.sh any time.

[tueda]

If we include the git revision information by git describe, the header line for private builds may become like

ParFORM 4.1 (May 10 2016, v4.1-20131025-182-g9b58d87-dirty) 64-bits 1023 workers  Run: Tue May 10 14:27:29 2016

Here the point is that v4.1-20131025-182-g9b58d87 is a valid commit identifier and copy and paste of it to your terminal does work. For release versions the header line can be shorter and may fit in 79 characters:

FORM 4.2 (May 10 2016, v4.2) 64-bits             Run: Tue May 10 14:27:29 2016

because git describe should give just v4.2. Or for Jos's build, it will be just

FORM 4.2 (May 10 2016) 64-bits                   Run: Tue May 10 14:27:29 2016

such that all information comes from form3.h (and possibly __DATE__ macro for the build date).

In summary, we could print the version information

• in 79 characters, when it fits,
• or more (up to 254) characters, which is dynamically determined.

[benruijl]

Sounds good! We can save 4 characters by dropping the 4.1 in ParFORM 4.1 in
your first example, since the version number is actually already included
in the tag.

2016-05-10 17:21 GMT+02:00 Takahiro Ueda notifications@github.com:

If we include the git revision information by git describe, the header
line for private builds may become like

ParFORM 4.1 (May 10 2016, v4.1-20131025-182-g9b58d87-dirty) 64-bits 1023 workers Run: Tue May 10 14:27:29 2016

Here the point is that v4.1-20131025-182-g9b58d87 is a valid commit
identifier and copy and paste of it to your terminal does work. For release
versions the header line can be shorter and may fit in 79 characters:

FORM 4.2 (May 10 2016, v4.2) 64-bits Run: Tue May 10 14:27:29 2016

because git describe should give just v4.2. Or for Jos's build, it will
be just

FORM 4.2 (May 10 2016) 64-bits Run: Tue May 10 14:27:29 2016

such that all information comes from form3.h (and possibly DATE macro for
the build date).

In summary, we could print the version information

• in 79 characters, when it fits,
• or more (up to 254) characters, which is dynamically determined.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#89 (comment)

[tueda]

We can save 4 characters by dropping the 4.1 in ParFORM 4.1 in your first example, since the version number is actually already included in the tag.

Well, for my convenience, I prefer keeping the major and minor versions "4.1". When you want to check FORM versions (for example, in the configure script for software using FORM), the easiest way is to check the first line of the FORM outputs (the major and minor versions, 32-bits or 64-bits, and you can also find a constraint for (commit date) by assuming (build date) >= (commit date)). If we allow two or more patterns, like FORM (May 10 2016, v4.2-182-g9b58d87-dirty) and FORM 4.2 (May 10 2016), the regular expression for parsing them would become messier.

I think the above change of the header format is OK for check/check.rb and python-form, which make use of the first line of the outputs.

[vermaseren]

Hi Takahiro,

Maybe we can replace the 64-bits by a single letter:
A: 32-bits
B: 64-bits
Leaves also space for the future.
You can also hack up the “Run:" a bit. (or take it out).

Jos

On 10 mei 2016, at 15:33, Takahiro Ueda notifications@github.com wrote:

Here I list the problems to be resolved and describe related information.

What is the preferred format of the version information?

The current format in the FORM outputs is like

ParFORM 4.1 (May 9 2016) 64-bits 1023 workers Run: Tue May 10 14:27:29 2016
which is fit in 79 characters. (I ignore BETA versions for now.) We may put the git revision of the last commit (say, the first 8 characters), or the date of the last commit, or the both. The date is more human-readable than the git revision, while the git revision is completely unique. But putting both the revision and the date makes the header line longer and it may not be fit in 79 characters. Do we want to remove some characters like 64-bits? Or do we want to allow more than 79 characters and/or 1 line?

Perhaps, we would think about the last lines of the outputs, too. See also #91 #91, which introduces extra lines at the end when -T option is used.

How do we update the version information?

It is nice if the version information is automatically updated when one checks out a revision/branch or modifies the source code (giving a dirty suffix), and only the parts affected by the change are rebuilt. The version information is referred in configure.ac (when autoreconf is executed) and startup.c. manualdate.tex and devrefdate.tex in the documents also use the date information, which is for now forcely updated. Such automatic updates must be embedded in the Autotools build system. On the other hand, one may want to work without the build system/git repository; copying source files from the repository to his/her own directory and building binaries with his/her own Makefiles. We need some fallbacks for such cases.

Currently, one may change the date version in the FORM outputs as follows:

Manually modify DATE variable in make, for example
make DATE='May 9 2016'
which is referred in compiling startup.c. One needs to delete object files *-startup.o for updates.

Tarballs generated by make dist.
When tarballs are generated from a git repository, the last commit date is recorded in sources/production-date.h (and also in manualdate.tex and devrefdate.tex for the document). The existence of this file is checked by configure, to make config.h include production-date.h. So it is enough to type the following commands for building executables with the last commit date:

./configure
make
Manually update production-date.h.
This may be done by

automake -i
scripts/gendate.sh -c -o sources/production-date.h
./configure
make
Note that gendate.sh should be executed before configure because the configure script checks if production-date.h exists, while one can update production-date.h by gendate.sh any time.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub #89 (comment)

[tueda]

I made a working example for maintaining the versions from tags in the git repository:

• https://github.com/tueda/test-versioning

based on ideas I found by googling, for example,

• https://www.mercurial-scm.org/wiki/VersioningWithMake
• https://github.com/git/git/blob/master/GIT-VERSION-GEN
• https://lists.gnu.org/archive/html/autoconf/2007-12/msg00027.html

Next I will consider to embed it into the FORM repository.

[tueda]

Work in progress in build42 branch in

https://github.com/tueda/form/tree/build42

To me, (at least in my environment) the automatic versioning is now working.

[tueda]

The topic branch is now merged to the master branch, so I close this issue.