- TODO: update INSTALL.txt to replace the autotools configure
instructions with cmake.
- TODO: update make build system to provide an equivalent to
autotools' `make dist` ?
- TODO: update / revise github actions, replace autotools-only
ones with cmake (e.g.: vmactions.yml for FreeBSD.)
Reference issue: https://github.com/libsdl-org/SDL/issues/6571
We want the library to come out as libSDL3.so.0 on Unix, or something
similar on other platforms. There's no need to have libSDL3-3.0.so.0,
because next time we intentionally break the API it should become libSDL4
anyway.
Partially implements #5626.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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>
The official source code release isn't much use unless it contains
everything that users and downstream distributions need to do a
new build, so check that it does.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is currently only done for the Linux Autotools build. The CMake
build does not add a significant amount of extra test coverage, and
Github Workflows run in an environment where `cmake` and `sudo cmake`
point to different executables, which makes it awkward to install into
/usr/local from CMake.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Some CI workers don't seem to understand `cmake -v`, and Windows' shell
doesn't understand `VERBOSE=1 cmake`.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is usually desirable for batch processing: it lets us see exactly
what is happening in the logs.
Signed-off-by: Simon McVittie <smcv@collabora.com>
