This is a preparation to check if our users find noticeable bugs in the
x86-64 target, before we can decide if we want to remove the i686 target
for good.
Per the release notes for 1.5.0, the CMake build is preferred going
forward. This lets us drop some Makefile patches and pass them as CMake
options instead, with the exception of disabling mold-wrapper.so.
While this loses quite a bit of accuracy (although to no apparent
decrease in emulation quality) , it helps avoiding the additional
overhead of the `clock_gettime` syscall (as `CLOCK_MONOTONIC_COARSE`
is forwarded using the mapped time page) and we don't have to do a
HPET timer read for each tick.
This results in a decrease of Serenity boot time from 1h16m down to
42m when running on Serenity.
We were previously comparing the hash against the hash after the initial
import, which caused us to regenerate patches every time as long as we
did have patches (even if they haven't changed at all) and the script
entirely missing that it should remove patches if the current commit is
the "import" commit.
I've lost more changes to "you forgot to push the changed commits to the
remote" than I'd like to admit, so let's just unify both and only ever
use the actual working repository for detemining whether any patches
have changed.
This stops us from mangling our LLVM patch names and titles when using
`./package.sh dev`, as they like to put their category names in square
brackets.
Those have been added to the Clang build script in
d4d6f2d945, and now that the Clang version
has been updated, everyone should have those symlinks already anyways.
There were only two packages making use of this functionality, but it
seems more sensible to have a fixed implementation for the cleaning of
ports - especially now they delete the entire build directory and/or
dist files.
The functionality for `./package.sh clean` was a bit weird: based on
whether you were working in dev mode, it would try to delete either
`$workdir` or `$nongit_workdir` and `*.out` from your `pwd`.
The new functionality is pretty clear: `./package.sh clean` deletes the
entire build directory for the port regardless of what mode you're in,
`./package.sh clean_dist` removes all `$files`, and
`./package.sh clean_all` does both.
Instead of overwriting the existing `-j` makeopt, we only append
options. This brings the build time for the Quake port down from 24.3s
to 4.4s on my machine.
Music (MIDI) works through TiMidity++ and OpenGL support works, but is
still very buggy. Sometimes PrBoom+ fails to load its own configuration
file, which can be worked around by deleting it.
Also add it as a dependency for the `SDL_mixer` and `SDL2_mixer` ports.
Eawpats GUS patches are installed as part of the port, because without
patches TiMidity++ is not able to generate any sound. The license for
these is "fameware", credit to Andrew Suffield:
https://lists.debian.org/debian-legal/2002/09/msg00137.html
Add two patches to allow Python's package manager to work on Serenity:
- The first one enables zlib module, which is needed for `ensurepip`
command;
- The second patch fixes pip downloads, so it's possible to install
packages from the PyPI repository.
SDL2 applications are prone to reinitializing the SDL components when,
for example, changing the display resolution. This would lead to
crashes since we were doing things in the wrong order.
* We now decouple `GLContext` from `SDL_Window` a bit more, allowing
the window to be destroyed before the GLContext.
* Do not quit the `GUI::Application`, let our event loop handle exiting
These changes allow changing the display resolution in the Quake3 port.
On Arch Linux, the build was picking up the system libsamplerate, which
is undesirable. Unlikely that it is needed on Serenity, so disabling it
is a good workaround.
The GLib repository contains several submodules which is part of the
build process, but the source code for these submodule is not part of
the Source code tarball generated by Gitlab. Switching to download the
Release tarball from download.gnome.org solves this issue. It first
became apparent in version 2.73.x.
Additional information at: https://gitlab.gnome.org/GNOME/glib/-/issues/2716
