Now that tracks and cars can also be loaded from GfLocalDir(), the
in-game download manager must only use this directory since write
permissions are not guaranteed on GfDataDir().
It provides no benefit to do so, since the object would be destroyed
anyway and therefore it would be impossible to reuse these pointers.
Doing so can only mask potential memory errors.
SDTrack was taking the ownership for track, a pointer to tTrack
allocated many layers above SDScenery::LoadScene. More specifically, it
is allocated by either TrackBuildEx or TrackBuildv1, and both would
allocate the tTrack instance via calloc(3) instead of C++'s new.
Attempting to `delete` a pointer *not* allocated by a previous call to
`new` is undefined behaviour according to the C++ standard. [1]
In fact, SDScenery::LoadScene did not even attempt to modify the
tTrack instance, so there was no need to take its ownership in the first
place.
[1]: https://en.cppreference.com/w/cpp/language/delete
This new function attempts to read a parameter file from GfLocalDir()
first, and from GfDataDir() if not successful.
This function will be useful to extract car and track data from both
directories. Having car and track data available from GfLocalDir() is
required to allow users downloading new cars and tracks without
administrator/root privileges.
Opening a file only to check whether it exists is resource-consuming for
no reason, since GfFileExists can achieve the same effect without
requiring to open a file.
car.h defines a bunch of macros with a leading underscore (e.g.: _name)
that can clash with symbols from other projects.
More specifically, the _name macro was causing header files from
OpenSceneGraph to break, since they already used _name for other
purposes.
This macro had already been removed by the commit below. Moreover,
in-tree builds are discouraged by CMake.
commit cf18241a16
Author: Xavier Del Campo Romero <xavi.dcr@tutanota.com>
Date: Sat Dec 28 14:13:38 2024 +0100
cmake: Get SD_DATADIR from speed-dreams-data package
CPack does not install to CMAKE_INSTALL_PREFIX, but
CPACK_PACKAGING_INSTALL_PREFIX. However, the executables' rpath
would still be configured for ${CMAKE_INSTALL_PREFIX}/${SD_LIBDIR}/lib
instead of ${CPACK_PACKAGING_INSTALL_PREFIX}/${SD_LIBDIR}/lib,
making executables to fail to find their respective shared libraries.
Unfortunately, CPACK_PACKAGING_INSTALL_PREFIX is not defined by CMake,
but CPack, so it is not available from this context, so this commit
assumes its default value. [1]
[1]: https://cmake.org/cmake/help/latest/variable/CPACK_PACKAGING_INSTALL_PREFIX.html
Having an uninstall target is unjustified extra maintenance burden for
no benefit.
Instead, it is recommended to install to a CMAKE_INSTALL_PREFIX that the
user can easily remove e.g.: by deleting a directory as a
non-privileged user.
According to the documentation [1], EXISTS only has well-defined
behaviour when an absolute path is given. This fixes a bug where
re-configuring the project would fail because CMake would inadverently
jump to the invalid branch.
[1]: https://cmake.org/cmake/help/latest/command/if.html#exists
networkingmenu.cpp was always being built, but the CLIENT_SERVER macro
was used to comment out the implementation. A more orthodox way to
achieve the same effect without relying on macros is to let the build
system decide whether this source file should be built.
The following commit is related to recent fixes on championship mode:
commit 4af7c4d6f028dabf677941f0b5cdb96bae392648
Author: Xavier Del Campo Romero <xavi.dcr@tutanota.com>
Date: Fri Jan 17 11:56:30 2025 +0100
raceman: Remove fixed driver lists
Drivers can be generated by users, driver indexes are re-computed on
startup and no drivers are provided on a fresh installation, so it is no
longer possible to set up a fixed list of drivers on each championship
type.
Some championships depend on a given car category (e.g.: "36GP") that
might have not been installed yet by the user.
Making the championship not available fixes a out-of-bounds access when
reading VecCarCategoryIds in driverselect.cpp.
Now that speed-dreams-data is available as a submodule, this allows the
build system to choose it for in-tree builds. Therefore, CMake will
perform in the following order:
1. Do not search the speed-dreams-data package if SD_ASSUME_DATADIR is
set.
2. Otherwise, do an in-tree build if the submodule has been updated.
3. Otherwise, search for the speed-dreams-data package on standard
locations and CMAKE_PREFIX_PATH and/or CMAKE_FIND_ROOT_PATH.
4. Otherwise, return an error message.
SD_HAS_DATADIR was rendered redundant, so it has been removed. However,
SD_DATADIR_INSTALL_PREFIX was introduced because it would not equal
SD_DATADIR_ABS for in-tree builds, where an installed version of the
speed-dreams-data package is not required.
In-tree builds now allow to generate NSIS installers with both code and
data.
There were several reasons behind splitting the old SVN monorepo in two
Git repositories:
- It made packaging for GNU/Linux distributions easier, since
speed-dreams-data would be often considered as a separate,
portable package, as typically done in other video games. For example,
0ad and 0ad-data, cube2 and cube2-data, and so on.
- It reduced the repository size for the engine repository as much as
possible, which is often desirable for CI/CD runs and developers with
poor connectivity and/or who only want to perform quick changes to the
source code. After all, speed-dreams-data is around 294 MiB as of the
time of this writing, whereas speed-dreams-code is around 36 MiB.
However, there are situations where having both repositories together is
desirable or even mandatory:
- In the case of Windows builds, both repositories must be configured by
the same top-level CMakeLists.txt so that files and targets from both
repositories are installed simultaneously, and therefore packaged into
the NSIS-based installers. Otherwise, it would require users to run two
separate installers, one for speed-dreams-code and another for
speed-dreams-data.
- Having a submodule makes which version from speed-dreams-data is
compatible with speed-dreams-code clearer.
- Not having a submodule required developers to both fetch the
speed-dreams-data repository and install it, which means double disk
space usage.
- Some users might still prefer to work on a monorepo and not have to
worry about installing speed-dreams-data beforehand.
- build-3rdparty.yml cross-builds all third-party dependencies for
Windows. This workflow is meant to be run only sparingly, since
it fetches source code from many repositories and takes a long time to
build.
- build-w64-mingw32.yml cross-builds the game engine and tools for
Windows. It requires a pre-existing build of the third-party libraries.
These get reflected by the web browser interface, enhancing readability.
However, splitting into different steps requires to specify the working
directory.
Even if most of the project follows the 4-space convention, 2 spaces
seems more comfortable for YAML files, specially for workflows where
deeper levels of indentations are common.
