pkgconfig files have no version number

[kermitdafrog8]

The pkgconfig files have no version number causing other applications not to detect proper version during configure process.

[diabonas]

All pkg-config files distributed by tpm2-tss do include a version field, e.g.

tpm2-tss/lib/tss2-esys.pc.in

Line 9 in 1ec41b4

Version: @VERSION@

What is the exact error message you see when running ./configure for one of the affected applications using tpm2-tss? And how did you obtain or build tpm2-tss?

[kermitdafrog8]

I downloaded the 3.2.0 source tarball. After installation in my /usr/lib64/pkgconfig directory I get files like this
Taken from the tss2-mu.pc file.

prefix=/usr
exec_prefix=${prefix}
libdir=/usr/lib64
includedir=${prefix}/include

Name: tss2-mu
Description: TPM2 type marshaling and unmarshaling library.
URL: https://github.com/tpm2-software/tpm2-tss
Version: (version missing here had to manually enter for the library needed to be found with proper version number)
Cflags: -I${includedir} -I${includedir}/tss2
Libs: -ltss2-mu -L${libdir}

The program said it found the dependency but didn't find the right version number to match required. The pkgconfig file showed no version number so I manually entered the version to fix the issue. This might not be an issue any more or just a fluke on my end but just wanted to make you aware of it.

[AndreasFuchsTPM]

Ok, I think I got the problem.
We retrieve the version from git. But the .tar.gz does not contain git information anymore...
That's bad...
@williamcroberts Should we move the git describe --tags from configure to bootstrap and somehow include it from a file into configure or what should we do ?

[williamcroberts]

@AndreasFuchsSIT the release packages do not require a git repo, so I am assuming when @kermitdafrog8 downloaded the source tarball, that was the one generated by github. That one does not work. The solution is to always use the release tarballs. I wish Github would let me turn off that feature. We probably need to make sure this is documented somewhere.

[AndreasFuchsTPM]

I guess the same is true, if you call bootstrap or autoconf on the release tarball (as per our instructions).
Since configure.ac is part of the release tarball this will in the end not work.
I guess my Question is: how do we remove configure.ac from the release tarball.
And of course we need to update the INSTALL.md

[kermitdafrog8]

Why not get the version number from the CHANGELOG?

[williamcroberts]

I guess the same is true, if you call bootstrap or autoconf on the release tarball (as per our instructions). Since configure.ac is

In my tarballs I didn't include bootstrap, so you would have to call autoconf directly which I don't think any of our instructions do.

part of the release tarball this will in the end not work. I guess my Question is: how do we remove configure.ac from the release tarball. And of course we need to update the INSTALL.md

[williamcroberts]

Why not get the version number from the CHANGELOG?

parsing, no real need to add that complexity. If you just get the distribution tarball and run ./configure, it all just works.

[AndreasFuchsTPM]

Why not get the version number from the CHANGELOG?

Because inbetween releases we do not update the CHANGELOG file but instead track changes in the github milestone.
So all dirty builds would fail.
EDIT: not fail, but report some old version instead of the current git commit...

Did you however call autoreconf or use the github-source-tarball ?

[AndreasFuchsTPM]

In my tarballs I didn't include bootstrap, so you would have to call autoconf directly which I don't think any of our instructions do.

Still, do you know how to remove configure.ac from distfiles ?

[williamcroberts]

Why not get the version number from the CHANGELOG?

Because inbetween releases we do not update the CHANGELOG file but instead track changes in the github milestone. So all dirty builds would fail.

Duh, good point. git describe handles all of that.

[williamcroberts]

In my tarballs I didn't include bootstrap, so you would have to call autoconf directly which I don't think any of our instructions do.

Still, do you know how to remove configure.ac from distfiles ?

no idea

[diabonas]

Something like git-version-gen might work: it tries to run git describe to get the version, but can fall back to a .tarball-version file embedded into release tarballs if that fails. It is used like

AC_INIT([tpm2-tss],
        [m4_esyscmd([build-aux/git-version-gen .tarball-version])],
        [https://github.com/tpm2-software/tpm2-tss/issues],
        [],
        [https://github.com/tpm2-software/tpm2-tss])

This way autoreconf can still be run on release tarballs (e.g. to apply patches to the build system) while preserving the version number. The auto-generated git-archive tarballs from GitHub still won't work, but I think this is out of scope anyway.

[gotthardp]

+1

Yocto/OpenEmbedded always calls autoreconf as a part of the standard processing of autotools-based recipes. I would also prefer if it was possible to call autoreconf on release tarballs without having the version information cleared. Removing configure.ac would make the situation for Yocto even worse: now I can at least patch the configure.ac with a static version number.

[gotthardp]

Actually, the tpm2-abrmd uses a different approach based on a VERSION file generated by bootstrap. This allows calling autoreconf and works perfectly with Yocto. Couldn't we just use this approach everywhere else too?

[williamcroberts]

Actually, the tpm2-abrmd uses a different approach based on a VERSION file generated by bootstrap. This allows calling autoreconf and works perfectly with Yocto. Couldn't we just use this approach everywhere else too?

That's fine, accomplishes the same task. Just make sure we add it to EXTRA_DIST so it gets rolled up into the release tarball.