allow overriding the version

umlaeute commented 9 months ago

currently the version is calculated from git describe: https://github.com/agfline/LibAAF/blob/c09538608e56dbf42c099c7d1afa5f48c9d2a3fd/GenerateVersionHeader.cmake#L6

if git cannot be found, this falls back to some dummy version: https://github.com/agfline/LibAAF/blob/c09538608e56dbf42c099c7d1afa5f48c9d2a3fd/GenerateVersionHeader.cmake#L19-L20

this is somewhat problematic for downstream projects that also use git for their own reasons (with different tags, and whatnot).

it would be great if you could add a LIBAFF_VERSION option that allows to override the calculated version.

umlaeute commented 9 months ago

alternatively (or: additionally), you might check if there is a ${PROJECT_SOURCE_DIR}/include/libaaf/version.h and prefer that over the generated version.h file (see also #15).

ideally, the https://github.com/agfline/LibAAF/releases would then ship with a pre-generated include/libaaf/version.h file (which is not tracked in git; this would make the release process somewhat more complicated though)

umlaeute commented 9 months ago

just for context, I'm speaking with my Debian hat on. I would like to package libaaf for Debian (and derivatives, like Ubuntu), mostly for the sake of ardour (similar to #13).

In Debian we import upstream sources into our own git-based packaging repository (so the calculated version does not match your expectation). When we do the actual build of a package, we do not build from the git-repository, but from an archive (so we would get the fallback dummy version number, which again is different from the one we get from our repository).

We are total fans of reproducible builds, so we would like to be able to fix all moving parts.

agfline commented 9 months ago

it would be great if you could add a LIBAFF_VERSION option that allows to override the calculated version.

It's done in 90d34b9

ideally, the https://github.com/agfline/LibAAF/releases would then ship with a pre-generated include/libaaf/version.h file (which is not tracked in git; this would make the release process somewhat more complicated though)

Do you have any clue on how I could generate a version.h file on each release and include it ? Thank you for your help !

umlaeute commented 9 months ago

well there are two ways:

do not track the version.h in git and instead create additional release assets when doing a release that contain the actual source tarball (as opposed to the git archive you get when clicking on the automatically added Source code button). either do this manually for each release, or use CIC/CD to automate this (here on github, checkout github actions)
do track the version.h in git, and change it at a release (and right after it). in some of my projects i have small scripts to do a release, that will create multiple commits and tag the right one, just for this purpose. it's obviously a little bit more work on the maintainer side but not that much (instead of just tagging a commit - which could be done in the webinterface, you have to run a script (on your local machine)).

the advantage of this approach is, that it's less confusing for the user. e.g. there are not multiple "Source code" downloads in the release assets, and (if you are doing source only releases), you don't even have to create proper "Github Releases", as the GitHub "tag" page will automatically provide all the data.

see e.g. https://github.com/grame-cncm/faust/releases/tag/2.69.3 for a repository that provides extra source tarballs (faust does it to include its standard libraries rather than a version.h file, but the idea is the same).

umlaeute commented 9 months ago

ah forgot: one thing i successfully use (for the 2nd option above) is to add a beaconfile to the repository that indicates that i want to use a git-calculated version (as opposed to the one encoded in the git-tracked version.h file).

basically, the buildsystem checks if a special file (e.g. .gitversion in the root of the project) exists. if it does (and the version is not manually overridden), use git describe to calculate a dynamic version. this .gitversion file is excluded from the git archives (using .gitattributes; see #20), so it is not present in the release tarballs: the build system now does not try to calculate the version but just takes the one from the version.h (or the one passed via cmdline flags)

umlaeute commented 9 months ago

EDIT scratch this. it seems i had a leftover /include/libaaf/version.h file (which i missed, because it is gitignored) from some prior config attempt.

i was going to close this as completed, but then it probably is not:

me@linux:<<SRCDIR>>/libAAF/_build$ cmake .. -DLIBAAF_VERSION=v1.2.3
-- The C compiler identification is GNU 13.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found Git: /usr/bin/git (found version "2.43.0")
┌─────────────────────┐
│ Compiling for Linux │
└─────────────────────┘
Building AAFIface and AAFExtract upon static library
-- Configuring done (0.1s)
-- Generating done (0.0s)
-- Build files have been written to: <<SRCDIR>>/libAAF/_build
me@linux:<<SRCDIR>>/libAAF/_build$ make version
Building v1.2.3
Built target version
me@linux:<<SRCDIR>>/libAAF/_build$ grep LIBAAF_VERSION include/libaaf/version.h
#ifndef LIBAAF_VERSION_H_
#define LIBAAF_VERSION_H_
#define LIBAAF_VERSION "v1.2.3"
#endif  /* LIBAAF_VERSION_H_ */
me@linux:<<SRCDIR>>/libAAF/_build$ make
Building v1.2.3
[  0%] Built target version
[  2%] Building C object CMakeFiles/aaf-shared.dir/src/LibCFB/LibCFB.c.o
[  5%] Building C object CMakeFiles/aaf-shared.dir/src/LibCFB/CFBDump.c.o
[  7%] Building C object CMakeFiles/aaf-shared.dir/src/AAFCore/AAFCore.c.o
[ 10%] Building C object CMakeFiles/aaf-shared.dir/src/AAFCore/AAFClass.c.o
[ 12%] Building C object CMakeFiles/aaf-shared.dir/src/AAFCore/AAFToText.c.o
[ 15%] Building C object CMakeFiles/aaf-shared.dir/src/AAFCore/AAFDump.c.o
[ 17%] Building C object CMakeFiles/aaf-shared.dir/src/AAFIface/AAFIface.c.o
[ 20%] Building C object CMakeFiles/aaf-shared.dir/src/AAFIface/AAFIParser.c.o
[ 22%] Building C object CMakeFiles/aaf-shared.dir/src/AAFIface/AAFIAudioFiles.c.o
[ 25%] Building C object CMakeFiles/aaf-shared.dir/src/AAFIface/RIFFParser.c.o
[ 27%] Building C object CMakeFiles/aaf-shared.dir/src/AAFIface/URIParser.c.o
[ 30%] Building C object CMakeFiles/aaf-shared.dir/src/AAFIface/ProTools.c.o
[ 32%] Building C object CMakeFiles/aaf-shared.dir/src/AAFIface/Resolve.c.o
<<SRCDIR>>/libAAF/src/AAFIface/Resolve.c: In function 'resolve_parse_aafObject_DescriptiveMarker':
<<SRCDIR>>/libAAF/src/AAFIface/Resolve.c:234:9: warning: 'aafi_newMarker' accessing 24 bytes in a region of size 8 [-Wstringop-overflow=]
  234 |         aafi_newMarker( aafi, aafi->ctx.current_markers_edit_rate, *start, ((length) ? *length : 0), name, comment, &RGBColor );
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<<SRCDIR>>/libAAF/src/AAFIface/Resolve.c:234:9: note: referencing argument 7 of type 'uint16_t *[3]' {aka 'short unsigned int *[3]'}
In file included from <<SRCDIR>>/libAAF/include/libaaf/AAFIParser.h:37,
                 from <<SRCDIR>>/libAAF/src/AAFIface/Resolve.c:24:
<<SRCDIR>>/libAAF/include/libaaf/AAFIface.h:941:14: note: in a call to function 'aafi_newMarker'
  941 | aafiMarker * aafi_newMarker( AAF_Iface *aafi, aafRational_t *editRate, aafPosition_t start, aafPosition_t length, wchar_t *name, wchar_t *comment, uint16_t *RVBColor[3] );
      |              ^~~~~~~~~~~~~~
[ 35%] Building C object CMakeFiles/aaf-shared.dir/src/common/utils.c.o
[ 37%] Building C object CMakeFiles/aaf-shared.dir/src/debug.c.o
[ 40%] Linking C shared library lib/libaaf.so
[ 40%] Built target aaf-shared
[ 42%] Building C object CMakeFiles/aaf-static.dir/src/LibCFB/LibCFB.c.o
[ 45%] Building C object CMakeFiles/aaf-static.dir/src/LibCFB/CFBDump.c.o
[ 47%] Building C object CMakeFiles/aaf-static.dir/src/AAFCore/AAFCore.c.o
[ 50%] Building C object CMakeFiles/aaf-static.dir/src/AAFCore/AAFClass.c.o
[ 52%] Building C object CMakeFiles/aaf-static.dir/src/AAFCore/AAFToText.c.o
[ 55%] Building C object CMakeFiles/aaf-static.dir/src/AAFCore/AAFDump.c.o
[ 57%] Building C object CMakeFiles/aaf-static.dir/src/AAFIface/AAFIface.c.o
[ 60%] Building C object CMakeFiles/aaf-static.dir/src/AAFIface/AAFIParser.c.o
[ 62%] Building C object CMakeFiles/aaf-static.dir/src/AAFIface/AAFIAudioFiles.c.o
[ 65%] Building C object CMakeFiles/aaf-static.dir/src/AAFIface/RIFFParser.c.o
[ 67%] Building C object CMakeFiles/aaf-static.dir/src/AAFIface/URIParser.c.o
[ 70%] Building C object CMakeFiles/aaf-static.dir/src/AAFIface/ProTools.c.o
[ 72%] Building C object CMakeFiles/aaf-static.dir/src/AAFIface/Resolve.c.o
<<SRCDIR>>/libAAF/src/AAFIface/Resolve.c: In function 'resolve_parse_aafObject_DescriptiveMarker':
<<SRCDIR>>/libAAF/src/AAFIface/Resolve.c:234:9: warning: 'aafi_newMarker' accessing 24 bytes in a region of size 8 [-Wstringop-overflow=]
  234 |         aafi_newMarker( aafi, aafi->ctx.current_markers_edit_rate, *start, ((length) ? *length : 0), name, comment, &RGBColor );
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<<SRCDIR>>/libAAF/src/AAFIface/Resolve.c:234:9: note: referencing argument 7 of type 'uint16_t *[3]' {aka 'short unsigned int *[3]'}
In file included from <<SRCDIR>>/libAAF/include/libaaf/AAFIParser.h:37,
                 from <<SRCDIR>>/libAAF/src/AAFIface/Resolve.c:24:
<<SRCDIR>>/libAAF/include/libaaf/AAFIface.h:941:14: note: in a call to function 'aafi_newMarker'
  941 | aafiMarker * aafi_newMarker( AAF_Iface *aafi, aafRational_t *editRate, aafPosition_t start, aafPosition_t length, wchar_t *name, wchar_t *comment, uint16_t *RVBColor[3] );
      |              ^~~~~~~~~~~~~~
[ 75%] Building C object CMakeFiles/aaf-static.dir/src/common/utils.c.o
[ 77%] Building C object CMakeFiles/aaf-static.dir/src/debug.c.o
[ 80%] Linking C static library lib/libaaf.a
[ 80%] Built target aaf-static
[ 82%] Building C object CMakeFiles/AAFInfo.dir/tools/AAFInfo.c.o
[ 85%] Building C object CMakeFiles/AAFInfo.dir/tools/common.c.o
[ 87%] Building C object CMakeFiles/AAFInfo.dir/tools/thirdparty/libTC.c.o
[ 90%] Linking C executable bin/AAFInfo
[ 90%] Built target AAFInfo
[ 92%] Building C object CMakeFiles/AAFExtract.dir/tools/AAFExtract.c.o
[ 95%] Building C object CMakeFiles/AAFExtract.dir/tools/common.c.o
[ 97%] Building C object CMakeFiles/AAFExtract.dir/tools/thirdparty/libTC.c.o
[100%] Linking C executable bin/AAFExtract
[100%] Built target AAFExtract
me@linux:<<SRCDIR>>/libAAF/_build$ ./bin/AAFInfo -h

AAFInfo
libAAF v0.0.0-unknown

[...]

so apparently my version v1.2.3 is ignored and AAFInfo reports the v0.0.0-unknown version.

agfline / LibAAF

allow overriding the version #16