Fix tarball versioning

[tim-griesbach]

Fix tarball versioning

This PR addresses among others the issue of tarball naming in the CMake build system. Previously, an uninitialized variable, git_version, was used for the version in the package name, leading to incorrect tarball names.

Moreover, this PR introduces a new CMake target GenerateVersionFile to generate the file .tarball-version analogous to the file used in the Autotools-based creation of a tarball in p4est.

Then the file .tarball-version is used by the script git-version-gen to get the version in the case .git is not present, as it is the case for creating a tarball. This ensures a correctly populated p4est_config.h after configuring in a tarball directory.

Currently, the CMake target GenerateVersionFile is only build if some arbitrary build command is executed. In particular calling only make package_source does not suffice to trigger .tarball-version's creation.

[cburstedde]

Thanks! This is one more step to get the CMake tarball behave a bit more like the autotools one. Ideally, building with one system from a tarball created by the other should work.

Would we need analogous code in libsc?

[tim-griesbach]

Would we need analogous code in libsc?

Yes, if this PR is ready, I will create an analogous PR in libsc.

[cburstedde]

I like the approach to replicate the autotools git-version-gen vs. .tarball-version behaviour as closely as possible. Is there any more to be done?

[cburstedde]

Would we need analogous code in libsc?

Yes, if this PR is ready, I will create an analogous PR in libsc.

Cool, if it all works, let's take it there.

[tim-griesbach]

I like the approach to replicate the autotools git-version-gen vs. .tarball-version behaviour as closely as possible. Is there any more to be done?

The only remaining question for this PR is that the file .tarball-version is not created if one calls make package_source in a fresh repository, i.e. a repository that was never used to compile code. As I described here, the usual way of expressing this dependency in CMake did not work for me.

For Autotools, make dist creates the .tarball-version file. On the other hand, make dist requires also a preceding call (bootstrap).

Given that this issue seems to appear for t8code as well, I am interested in their perspective on this issue (cf. conversation in #325). If this does not lead to a solution, I could take a deeper dive and try to find a workaround.

[cburstedde]

Thanks; should we merge at this point and fix the issue about calling some first build command later?

With p4est, calling bootstrap is only needed on a fresh repository checkout; on unpacking a tarball bootstrap is not required. How does CMake behave when executed from an unpacked tarball?

(We still produce different tarballs from automake and CMake. Hoping they'll get closer, eventually.)

[tim-griesbach]

Thanks; should we merge at this point and fix the issue about calling some first build command later?

Sounds good to me! I pushed one small change to ensure full symmetry to the analogous code in lisbc by using the CMake project name in the name of the target that generates .tarball-version.

With p4est, calling bootstrap is only needed on a fresh repository checkout; on unpacking a tarball bootstrap is not required. How does CMake behave when executed from an unpacked tarball?

In CMake the workflow from an unpacked tarball is the same as for a the git repository, i.e. calling the cmake command to configure and then build the code.