KhronosGroup / KTX-Software

KTX (Khronos Texture) Library and Tools
Other
834 stars 222 forks source link

Allow KTX_VERSION_FULL to be manually specified #922

Open xoofx opened 3 weeks ago

xoofx commented 3 weeks ago

Hello,

I would like to add ktx as a package to Alpine Linux, and one requirement is to be able to build from a tar.gz published from v4.3.2) but the current cmake/version.cmake is forcing to build from the original git repo, while when building within Alpine aports, we specify the version ourselves as part of the Alpine build system (automatically from the tar.gz downloaded).

This PR is making a small change to cmake/version.cmake to allow to pass KTX_VERSION_FULL to cmake.

CLAassistant commented 3 weeks ago

CLA assistant check
All committers have signed the CLA.

MarkCallow commented 2 weeks ago

(automatically from the tar.gz downloaded)

What is the information contained in the downloaded tar.gz? Is it the name of the git tag?

xoofx commented 2 weeks ago

What is the information contained in the downloaded tar.gz? Is it the name of the git tag?

Oh, maybe this was not clear.

When we go to the release tab here to the latest version https://github.com/KhronosGroup/KTX-Software/releases/tag/v4.3.2

At the bottom we can download the tar.gz snapshot of this repository:

image

Which gives a link to https://github.com/KhronosGroup/KTX-Software/archive/refs/tags/v4.3.2.tar.gz

If you download this file and try to build from source, you will get a 0.0.0.0 version number because it is failing to resolve the Version number from git.

This PR is allowing to specify the version to cmake when we know about it (we download a specific version through a tag), so we can build this repository without doing a git checkout by just using the artifacts. This is a requirement for Alpine Linux to be able to build from tar.gz.

Hope that clarifies.

MarkCallow commented 2 weeks ago

The only bit that wasn't, and still isn't, clear is "automatically from the tar.gz downloaded". I get you download the artifacts for a particular tag and I get that absent the git repo the version.cmake does not produce a version. Is the automatic part something in the tar.gz, which is implied by "from" or is it that your scripts request a particular tag and use that same tag name when creating the full version?

I want to understand how easy or otherwise it is for your system to create a totally nonsense version number.

In this scenario how do you correctly create the various version.h files that are included in the commands to support their --version queries? These are create by scripts/mkversion but I think also rely on having the git repo.

xoofx commented 2 weeks ago

I want to understand how easy or otherwise it is for your system to create a totally nonsense version number.

Ok, the number is specified when we download a version. So, it's not totally nonsense, because it is the actual tag on this repo. And this repo is using the actual tag to make the version number, so we are matching this accordingly. But to explain this further, the following should explain how packages in Alpine Linux are built:

Alpine linux is using a custom build system to build packages. This is stored in an APKBUILD file in their repo.

For example, at this line, You see the version number: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/allegro/APKBUILD#L4

# Contributor: Bart Ribbers <bribbers@disroot.org>
# Maintainer: Bart Ribbers <bribbers@disroot.org>
pkgname=allegro
pkgver=5.2.9.1

At the following line here https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/allegro/APKBUILD#L27 you have the URL to GitHub to download the package:

source="https://github.com/liballeg/allegro5/releases/download/$pkgver/allegro-$pkgver.tar.gz"
subpackages="$pkgname-dev"

The download package is matching the git version.

In this scenario how do you correctly create the various version.h files that are included in the commands to support their --version queries? These are create by scripts/mkversion but I think also rely on having the git repo.

With this PR, I can pass the $pkgver to KTX_VERSION_FULL and it should propagate within the build system. That's what I got from the binaries that I built. Do you mean that outside of cmake, there are other places that we fetch the git tag?

xoofx commented 2 weeks ago

That's what I got from the binaries that I buil

That being said, I think I checked only libktx, but looking at cmake scripts, for tools, it looks like we are delegating this to scripts/mkversion via create_version_header that is creating that for each tool. Is that correct?

xoofx commented 2 weeks ago

I could propagate the tag to the mkversion with e.g a special argument like --version or something like this. Would that be enough?

MarkCallow commented 2 weeks ago

scripts/mkversion predates use of CMake and creation of cmake/version.cmake. I don't know if it is reasonable to combine them. Passing a --version argument as you propose seems like a reasonable alternative.

MarkCallow commented 1 week ago

I could propagate the tag to the mkversion with e.g a special argument like --version or something like this. Would that be enough?

Are you working on this?

xoofx commented 1 week ago

Are you working on this?

Yes, I will do it on my spare time.