Remove git versioning (unused)

[nclack]

In an effort to get rid of warnings like: "GIT_TAG and GIT_HASH redefined", I'm going through and fixing up git-versioning.cmake scripts.

Here though, none of the targets build by core libs use GIT_TAG or GIT_HASH so I'm removing the script.

[aliddell]

lgtm

[andy-sweet]

What does usage of the GIT_TAG and GIT_HASH definitions look like?

One consumer was CPACK (in CPACK_PACKAGE_VERSION), but that didn't need them be compile time definitions, right? I noticed that we don't actually call cpack anywhere in this repo - does that mean we could also remove include(CPack) in the top-level CMakeLists.txt? Or do we want/need targets that produces for other reasons?

The only other consumer I found of either of these definitions is in acquire-video-runtime: https://github.com/acquire-project/acquire-video-runtime/blob/773a6f5e863e4356c2d19666b5a12fde133dbaba/src/acquire.c#L76

Could we just remove these definitions everywhere except there?

[nclack]

Could we just remove these definitions everywhere except there?

I'm inclined to update the drivers.

If we do the update, the versions get reported during the cmake build.

Also, we don't use GIT_TAG and GIT_HASH in the drivers, but we probably should - there are pretty good reasons to have drivers report their own versions to the acquire runtime for reporting purposes.

[nclack]

could also remove include(CPack)

cpack gets invoked as a command line tool. It uses a bunch of variables that get defined by that include(CPack) step. Modifying CPACK_PACKAGE_VERSION in that top level git-versioning script works because of cmake's directory scoping rules (I think). It ends up setting the version used in the name of the installer/package that cpack produces.

[andy-sweet]

could also remove include(CPack)

cpack gets invoked as a command line tool. It uses a bunch of variables that get defined by that include(CPack) step. Modifying CPACK_PACKAGE_VERSION in that top level git-versioning script works because of cmake's directory scoping rules (I think). It ends up setting the version used in the name of the installer/package that cpack produces.

Sure. But cpack is never invoked from the command line in this repo (e.g. by a workflow). I guess it's nice to have the option to package/install acquire-core-libs though, so no need to remove.