mirrors
/
SDL
mirror of https://github.com/libsdl-org/SDL
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
SDL/build-scripts/updaterev.sh

49 lines
1.1 KiB
Bash
Raw Permalink Normal View History

Fixed crash if initialization of EGL failed but was tried again later. The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly uninitialized data structure if loading the library first failed. A later try to use EGL then skipped initialization and assumed it was previously successful because the data structure now already existed. This led to at least one crash in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was dereferenced to make a call to eglBindAPI().
2015-06-21 18:33:46 +03:00
#!/bin/sh
#
# Generate a header file with the current source revision
outdir=`pwd`
cd `dirname $0`
srcdir=..
Switch header convention from `#include "SDL.h"` to `#include <SDL3/SDLh>` I ran this script in the include directory: ```sh sed -i '' -e 's,#include "\(SDL.*\)",#include <SDL3/\1>,' *.h ``` I ran this script in the src directory: ```sh for i in ../include/SDL3/SDL*.h do hdr=$(basename $i) if [ x"$(echo $hdr | egrep 'SDL_main|SDL_name|SDL_test|SDL_syswm|SDL_opengl|SDL_egl|SDL_vulkan')" != x ]; then find . -type f -exec sed -i '' -e 's,#include "\('$hdr'\)",#include <SDL3/\1>,' {} \; else find . -type f -exec sed -i '' -e '/#include "'$hdr'"/d' {} \; fi done ``` Fixes https://github.com/libsdl-org/SDL/issues/6575
2022-11-27 07:43:38 +03:00
header=$outdir/include/SDL3/SDL_revision.h
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 21:54:24 +03:00
dist=
build: Add a mechanism to mark builds with vendor info Downstream distributors can use this to mark a version with their preferred version information, like a Linux distribution package version or the Steam revision it was built to be bundled into, or just to mark it with the vendor it was built by or the environment it's intended to be used in. For instance, in Debian I'd use this by configuring with: --enable-vendor-info="${DEB_VENDOR} ${DEB_VERSION}" to get a SDL_REVISION like: release-2.24.1-0-ga1d1946dc (Debian 2.24.1+dfsg-2) which gives a Debian user enough information to track down the patches and build-time configuration that were used for package revision 2. In Autotools and CMake, this is a configure-time option like any other, and will go into both SDL_REVISION (via SDL_revision.h) and SDL_GetRevision(). In other build systems (MSVC, Xcode, etc.), defining the SDL_VENDOR_INFO macro will get it into the output of SDL_GetRevision(), although not SDL_REVISION. Resolves: https://github.com/libsdl-org/SDL/issues/6418 Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-10-20 22:02:21 +03:00
vendor=
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 21:54:24 +03:00
while [ "$#" -gt 0 ]; do
case "$1" in
(--dist)
dist=yes
shift
;;
build: Add a mechanism to mark builds with vendor info Downstream distributors can use this to mark a version with their preferred version information, like a Linux distribution package version or the Steam revision it was built to be bundled into, or just to mark it with the vendor it was built by or the environment it's intended to be used in. For instance, in Debian I'd use this by configuring with: --enable-vendor-info="${DEB_VENDOR} ${DEB_VERSION}" to get a SDL_REVISION like: release-2.24.1-0-ga1d1946dc (Debian 2.24.1+dfsg-2) which gives a Debian user enough information to track down the patches and build-time configuration that were used for package revision 2. In Autotools and CMake, this is a configure-time option like any other, and will go into both SDL_REVISION (via SDL_revision.h) and SDL_GetRevision(). In other build systems (MSVC, Xcode, etc.), defining the SDL_VENDOR_INFO macro will get it into the output of SDL_GetRevision(), although not SDL_REVISION. Resolves: https://github.com/libsdl-org/SDL/issues/6418 Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-10-20 22:02:21 +03:00
(--vendor)
vendor="$2"
shift 2
;;
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 21:54:24 +03:00
(*)
echo "$0: Unknown option: $1" >&2
exit 2
;;
esac
done
Fixed crash if initialization of EGL failed but was tried again later. The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly uninitialized data structure if loading the library first failed. A later try to use EGL then skipped initialization and assumed it was previously successful because the data structure now already existed. This led to at least one crash in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was dereferenced to make a call to eglBindAPI().
2015-06-21 18:33:46 +03:00
rev=`sh showrev.sh 2>/dev/null`
Updated the revision header with git revision
2021-02-12 19:50:16 +03:00
if [ "$rev" != "" ]; 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 21:54:24 +03:00
if [ -n "$dist" ]; then
Save the version in VERSION.txt instead of VERSION Fixes https://github.com/libsdl-org/SDL/issues/6558
2022-11-21 17:57:02 +03:00
echo "$rev" > "$outdir/VERSION.txt"
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 21:54:24 +03:00
fi
echo "/* Generated by updaterev.sh, do not edit */" >"$header.new"
build: Add a mechanism to mark builds with vendor info Downstream distributors can use this to mark a version with their preferred version information, like a Linux distribution package version or the Steam revision it was built to be bundled into, or just to mark it with the vendor it was built by or the environment it's intended to be used in. For instance, in Debian I'd use this by configuring with: --enable-vendor-info="${DEB_VENDOR} ${DEB_VERSION}" to get a SDL_REVISION like: release-2.24.1-0-ga1d1946dc (Debian 2.24.1+dfsg-2) which gives a Debian user enough information to track down the patches and build-time configuration that were used for package revision 2. In Autotools and CMake, this is a configure-time option like any other, and will go into both SDL_REVISION (via SDL_revision.h) and SDL_GetRevision(). In other build systems (MSVC, Xcode, etc.), defining the SDL_VENDOR_INFO macro will get it into the output of SDL_GetRevision(), although not SDL_REVISION. Resolves: https://github.com/libsdl-org/SDL/issues/6418 Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-10-20 22:02:21 +03:00
if [ -n "$vendor" ]; then
echo "#define SDL_VENDOR_INFO \"$vendor\"" >>"$header.new"
fi
echo "#ifdef SDL_VENDOR_INFO" >>"$header.new"
echo "#define SDL_REVISION \"SDL-$rev (\" SDL_VENDOR_INFO \")\"" >>"$header.new"
echo "#else" >>"$header.new"
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 21:54:24 +03:00
echo "#define SDL_REVISION \"SDL-$rev\"" >>"$header.new"
build: Add a mechanism to mark builds with vendor info Downstream distributors can use this to mark a version with their preferred version information, like a Linux distribution package version or the Steam revision it was built to be bundled into, or just to mark it with the vendor it was built by or the environment it's intended to be used in. For instance, in Debian I'd use this by configuring with: --enable-vendor-info="${DEB_VENDOR} ${DEB_VERSION}" to get a SDL_REVISION like: release-2.24.1-0-ga1d1946dc (Debian 2.24.1+dfsg-2) which gives a Debian user enough information to track down the patches and build-time configuration that were used for package revision 2. In Autotools and CMake, this is a configure-time option like any other, and will go into both SDL_REVISION (via SDL_revision.h) and SDL_GetRevision(). In other build systems (MSVC, Xcode, etc.), defining the SDL_VENDOR_INFO macro will get it into the output of SDL_GetRevision(), although not SDL_REVISION. Resolves: https://github.com/libsdl-org/SDL/issues/6418 Signed-off-by: Simon McVittie <smcv@collabora.com>
2022-10-20 22:02:21 +03:00
echo "#endif" >>"$header.new"
Fixed crash if initialization of EGL failed but was tried again later. The internal function SDL_EGL_LoadLibrary() did not delete and remove a mostly uninitialized data structure if loading the library first failed. A later try to use EGL then skipped initialization and assumed it was previously successful because the data structure now already existed. This led to at least one crash in the internal function SDL_EGL_ChooseConfig() because a NULL pointer was dereferenced to make a call to eglBindAPI().
2015-06-21 18:33:46 +03:00
if diff $header $header.new >/dev/null 2>&1; then
rm "$header.new"
else
mv "$header.new" "$header"
fi
fi