If a developer built cmake (or we built it for them) from source, make
sure that port builds can find that version of CMake that has the
SerenityOS platform files included.
:yakkie:
The build process for the Zig compiler is more involved than most of
the other ports, because the Zig compiler is mostly self-hosting. In
order to build it, the zig-bootstrap build system is used, which does
the following:
1) Build LLVM for the host OS;
2) Build Zig for the host OS with the SerenityOS target enabled;
3) Build zlib, zstd and LLVM for SerenityOS using `zig cc` as the C/C++
compiler;
4) Build Zig for SerenityOS using the host Zig.
A few hacks are required in order to tell `zig cc` and zig about what
Serenity's libc looks like in the build process, but other than that
it's fairly straightforward. All of the patches that are included with
this commit are Zig-upstream ready once the LLVM patches are upstreamed.
When using cmake --build, CMake will look for this environment variable
to enable parallelism. The Zig port, for example, uses cmake --build,
and will otherwise use a single core if cmake selects Make as the build
system. This should help with all ports which use cmake --build.
We have a new, improved string type coming up in AK (OOM aware, no null
state), and while it's going to use UTF-8, the name UTF8String is a
mouthful - so let's free up the String name by renaming the existing
class.
Making the old one have an annoying name will hopefully also help with
quick adoption :^)
This makes the port install drop the CMake install files into the
sysroot, which is friendlier to macOS users. Homebrew CMake really
likes to pick homebrew zstd, even for cross-builds.
When building a port with `useconfigure="false"`, the `do_configure`
function invokes a `buildstep` with multiple positional arguments as the
command to execute.
It then tests whether the positional arguments evaluate to an emtpy
string, but could fail when multiple positional arguments were provided.
This resulted in the following warning when building the Composer port,
for example:
../.port_include.sh: line 16: [: echo: binary operator expected
Prevent this warning by testing against the number of positional
arguments, instead.
Since ac40197047 LibCrypt has its own library. PHP tries to detect the
`crypt_data` struct but fails to do so since it cannot find `crypt.h`.
By adding this explicit include path, PHP builds again.
These were no longer being picked up after some recent changes. Since
port builds happen in subshells nowadays, we can get rid of the export /
unset combo anyway.
This fixes ScummVM crashing on startup, caused by `-fvisibility` not
being set.
This now requires `--host` and `--with-build-python` to be passed to the
configure script when cross compiling; the former we simply do like in
many other package.sh scripts as well, the latter we point to `python3`,
which is expected to match the port's version anyway.
previously every buildstep would return a success error code. As a
result, all the steps would run even if previous steps failed.
I've also added a red status message when this happens.
This patch fixes libopenal's build by disabling the alsoft-config
utility which required qt6, and disabling the example programs that were
causing compiler errors.
This also forces CMake to build with an SDL2 backend so audio can
actually be played.
We used to do whole bunch of unnecessary things in the install sequence
which the default port_include script sequence can do just fine,
therefore the install sequence is removed from the port script.
The post_install sequence wrongly called "make install-bin" which could
be done in the default install sequence, as well as to create the /bin
directory which is completely unnecessary to do because the image build
script already does that for us. Also, now /usr/local/bin is in the PATH
environment variable, so the installed binaries are runnable without
creating symlinks in the /bin directory, therefore making the sequence
of post_install completely unnecessary in the script so it is removed
too.
Replace the manual creation of symlinks with the
`--enable-compat-symlinks` configure option, which automatically creates
the symlinks that we want and more.
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.
