2015-06-21 09:33:46 -06:00
|
|
|
#!/bin/sh
|
|
|
|
#
|
|
|
|
# Print the current source revision, if available
|
|
|
|
|
2020-04-08 09:41:55 -06:00
|
|
|
SDL_ROOT=$(dirname $0)/..
|
|
|
|
cd $SDL_ROOT
|
|
|
|
|
build: Expand version info in SDL_REVISION and SDL_GetRevision()
Instead of using a URL and git sha1, this uses `git describe` to
describe the version relative to the nearest previous git tag, which
gives a better indication of whether this is a release, a prerelease,
a slightly patched prerelease, or a long way after the last release
during active development.
This serves two purposes: it makes those APIs more informative, and it
also puts this information into the binary in a form that is easy to
screen-scrape using strings(1). For instance, if the bundled version of
SDL in a game has this, we can see at a glance what version it is.
It's also shorter than using the web address of the origin git
repository and the full git commit sha1.
Also write the computed version into a file ./VERSION in `make dist`
tarballs, so that when we build from a tarball on a system that doesn't
have git available, we still get the version details.
For the Perforce code path in showrev.sh, output the version number
followed by the Perforce revision, in a format reminiscent of
`git describe` (with p instead of g to indicate Perforce).
For the code path with no VCS available at all, put a suffix on the
version number to indicate that this is just a guess (we can't know
whether this SDL version is actually a git snapshot or has been
patched locally or similar).
Resolves: https://github.com/libsdl-org/SDL/issues/6418
Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-10-20 12:54:24 -06:00
|
|
|
if [ -e ./VERSION ]; then
|
|
|
|
cat ./VERSION
|
|
|
|
exit 0
|
|
|
|
fi
|
|
|
|
|
|
|
|
major=$(sed -ne 's/^#define SDL_MAJOR_VERSION *//p' include/SDL_version.h)
|
|
|
|
minor=$(sed -ne 's/^#define SDL_MINOR_VERSION *//p' include/SDL_version.h)
|
|
|
|
micro=$(sed -ne 's/^#define SDL_PATCHLEVEL *//p' include/SDL_version.h)
|
|
|
|
version="${major}.${minor}.${micro}"
|
|
|
|
|
2021-02-12 09:50:16 -07:00
|
|
|
if [ -x "$(command -v git)" ]; then
|
build: Expand version info in SDL_REVISION and SDL_GetRevision()
Instead of using a URL and git sha1, this uses `git describe` to
describe the version relative to the nearest previous git tag, which
gives a better indication of whether this is a release, a prerelease,
a slightly patched prerelease, or a long way after the last release
during active development.
This serves two purposes: it makes those APIs more informative, and it
also puts this information into the binary in a form that is easy to
screen-scrape using strings(1). For instance, if the bundled version of
SDL in a game has this, we can see at a glance what version it is.
It's also shorter than using the web address of the origin git
repository and the full git commit sha1.
Also write the computed version into a file ./VERSION in `make dist`
tarballs, so that when we build from a tarball on a system that doesn't
have git available, we still get the version details.
For the Perforce code path in showrev.sh, output the version number
followed by the Perforce revision, in a format reminiscent of
`git describe` (with p instead of g to indicate Perforce).
For the code path with no VCS available at all, put a suffix on the
version number to indicate that this is just a guess (we can't know
whether this SDL version is actually a git snapshot or has been
patched locally or similar).
Resolves: https://github.com/libsdl-org/SDL/issues/6418
Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-10-20 12:54:24 -06:00
|
|
|
rev="$(git describe --tags --long 2>/dev/null)"
|
|
|
|
if [ -n "$rev" ]; then
|
|
|
|
# e.g. release-2.24.0-542-g96361fc47
|
|
|
|
# or release-2.24.1-5-g36b987dab
|
|
|
|
# or prerelease-2.23.2-0-gcb46e1b3f
|
|
|
|
echo "$rev"
|
|
|
|
exit 0
|
|
|
|
fi
|
|
|
|
|
|
|
|
rev="$(git describe --always --tags --long 2>/dev/null)"
|
|
|
|
if [ -n "$rev" ]; then
|
|
|
|
# Just a truncated sha1, e.g. 96361fc47.
|
|
|
|
# Turn it into e.g. 2.25.0-g96361fc47
|
|
|
|
echo "${version}-g${rev}"
|
2020-04-08 09:41:55 -06:00
|
|
|
exit 0
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
|
|
|
|
if [ -x "$(command -v p4)" ]; then
|
|
|
|
rev="$(p4 changes -m1 ./...\#have 2>/dev/null| awk '{print $2}')"
|
2020-04-29 09:32:08 -06:00
|
|
|
if [ $? = 0 ]; then
|
build: Expand version info in SDL_REVISION and SDL_GetRevision()
Instead of using a URL and git sha1, this uses `git describe` to
describe the version relative to the nearest previous git tag, which
gives a better indication of whether this is a release, a prerelease,
a slightly patched prerelease, or a long way after the last release
during active development.
This serves two purposes: it makes those APIs more informative, and it
also puts this information into the binary in a form that is easy to
screen-scrape using strings(1). For instance, if the bundled version of
SDL in a game has this, we can see at a glance what version it is.
It's also shorter than using the web address of the origin git
repository and the full git commit sha1.
Also write the computed version into a file ./VERSION in `make dist`
tarballs, so that when we build from a tarball on a system that doesn't
have git available, we still get the version details.
For the Perforce code path in showrev.sh, output the version number
followed by the Perforce revision, in a format reminiscent of
`git describe` (with p instead of g to indicate Perforce).
For the code path with no VCS available at all, put a suffix on the
version number to indicate that this is just a guess (we can't know
whether this SDL version is actually a git snapshot or has been
patched locally or similar).
Resolves: https://github.com/libsdl-org/SDL/issues/6418
Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-10-20 12:54:24 -06:00
|
|
|
# e.g. 2.25.0-p7511446
|
|
|
|
echo "${version}-p${rev}"
|
2020-04-08 09:41:55 -06:00
|
|
|
exit 0
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
|
build: Expand version info in SDL_REVISION and SDL_GetRevision()
Instead of using a URL and git sha1, this uses `git describe` to
describe the version relative to the nearest previous git tag, which
gives a better indication of whether this is a release, a prerelease,
a slightly patched prerelease, or a long way after the last release
during active development.
This serves two purposes: it makes those APIs more informative, and it
also puts this information into the binary in a form that is easy to
screen-scrape using strings(1). For instance, if the bundled version of
SDL in a game has this, we can see at a glance what version it is.
It's also shorter than using the web address of the origin git
repository and the full git commit sha1.
Also write the computed version into a file ./VERSION in `make dist`
tarballs, so that when we build from a tarball on a system that doesn't
have git available, we still get the version details.
For the Perforce code path in showrev.sh, output the version number
followed by the Perforce revision, in a format reminiscent of
`git describe` (with p instead of g to indicate Perforce).
For the code path with no VCS available at all, put a suffix on the
version number to indicate that this is just a guess (we can't know
whether this SDL version is actually a git snapshot or has been
patched locally or similar).
Resolves: https://github.com/libsdl-org/SDL/issues/6418
Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-10-20 12:54:24 -06:00
|
|
|
# best we can do
|
|
|
|
echo "${version}-no-vcs"
|
|
|
|
exit 0
|