| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
nielsmh nicely correct us in #8641, pointing out the old comment
is not telling a complete truth. The result is the same, but it
is better to not mislead future-us.
|
|
|
|
These bundles can be opened on any "modern" Linux machine with
a driver that SDL2 supports.
Machines needs at least glibc 2.15, which was released 10 years ago.
It is build with CentOS 7 as base, and only assumes the following
libraries are available on the system:
- libc
- libdl
- libgcc_s
- libpthread
- librt
- libstdc++
All other libraries the game depends on are bundled together with
the game, so users don't need any library installed to use this
bundle. The downside of course is that this increases the binary
size a bit: 30 MiB of libraries are in this bundle.
RPATH is used to make ld-linux find the folder libraries are
stored in; however, system libraries are always used before these,
in the assumption libraries on the user system are more up-to-date.
Using -DOPTION_PACKAGE_DEPENDENCIES=ON switches on packaging
of libraries in the "lib" folder. This requires CMake 3.16 to
be installed; otherwise it will fail.
|
|
This was already removed from the "ci-build", but not yet from
"release".
|
|
|
|
|
|
|
|
|
|
|
|
This was already applied on the CI build, but not yet on the
release build.
|
|
|
|
|
|
|
|
|
|
Because certain files are read-only, the "restore-cache" step
fails, as Windows tar refuses to overwrite those files (even
if they are identical). Instead of hoping upstream fixes
"restore-cache", just remove the read-only flag on these files
instead.
|
|
directories ourselves
|
|
We use CMakeListsTxtAdvanced, and as such, we have to do this our
self via "-DCMAKE_BUILD_TYPE=RelWithDebInfo". Otherwise we are
producing Debug builds instead of Release builds. Oops.
|
|
|
|
This has several ways of being triggered:
- When creating a new release via the GitHub interface. Fully
automated that will produce new binaries, upload them, and it
will even update the website to tell about the new version.
- When triggered in an automated way from OpenTTD/workflows to
start a nightly.
- Manually via the Release workflow, which accepts branches,
Pull Requests and tags to build.
Rerunning a job is safe and should be without issues. Everything
retriggers and updates what-ever might have been broken. In fact,
except for dates, it should produce identical results.
Co-authored-by: Charles Pigott <charlespigott@googlemail.com>
|
|
When a developer attaches the "preview" label, a build is created
and published on https://preview.openttd.org/. After that, new
pushes to the PR are automatically build (as long as the "preview"
label exists).
If a non-developer attaches the "preview" label, it will be
removed.
|
|
Emscripten compiles to WASM, which can be loaded via
HTML / JavaScript. This allows you to play OpenTTD inside a
browser.
Co-authored-by: milek7 <me@milek7.pl>
|
|
Also, while at it, make it more like the upcoming release-workflow,
so they look a lot more similar.
Functional it should be the same, except that Windows should
now also output when a test fails.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Stale bot checks if an issue hasn't had any attention in the last
60 days, or if a pull request hasn't had any attention in the last
30 days. If so, it marks it as stale. After 7 more days, it closes
the issue/pull request. Any activity on the issue/pull request
resets the timer.
This helps keeping the counter low, and the work manageable. There
is a lot of reasoning behind this idea, and other projects show it
really helps to keep the issue/pull request count low.
More information here: https://github.com/probot/stale
|
