These existed because of their `vcpkg_ci` base preset, whose goal was to
enable vcpkg-supported caching on GitHub. We now handle vcpkg caching in
the CI steps, removing the necessity for all these *_CI preset variants.
This allows us to reuse `inputs.build_preset` in the test step, and we
can do away with the Windows-specific test step since it is now almost
identical to the Linux/macOS test step.
I've left in the Windows_CI presets, because that one actually results
in a different set of compiled files compared to the
Windows_Experimental presets.
I've set up a shared vcpkg source assets cache using Azurite. By
default, it runs in read-only mode allowing anyone who builds Ladybird
to use the cache to speed up downloads of source tarballs. This should
alleviate some of the more slower vcpkgs downloads I've been seeing
lately.
CI runs on master put vcpkg in readwrite mode, updating the cache for
everyone.
As we now are only officially supporting the Ninja generator for
Windows, the old preset structure can now be simplified. Also, we
now follow the naming conventions of the non-hidden presets.
This will allow us to gradually build up official support for Windows,
as only targets we have explicitly marked as supported on windows will
be built and ran during CI.
This is a workaround for the deprecation of the cache v1 REST API that
was replaced with a new protobuf RPC based API this month. vcpkg was
using the private cache backend API without the knowledge of the GitHub
actions team, and was thus broken by the deprecation.
While we wait for Microsoft to talk to Microsoft to get this feature
restored, we can use the raw actions/cache step to get almost the same
cache behavior. The only difference is that the cache will be less fine
grained than the per-package cache that VCPKG_BINARY_SOURCES of x-gha
was giving us before.
Becuase we're using dynamic libraries, our configuration is
classified as a "community triplet". To not confuse vcpkg
maintainers when developers create bug reports, name them
properly. This means that the default triplet detection is now
kind of useless, so we have to invent our own for these triplets.
Instead of writing ASAN and UBSAN output into the same stream we use for
test logging, direct them to log files, named asan.log.$PID and
ubsan.log.$PID, and then output them in a separate CI job that runs
afterwards. This should hopefully make it easier to see which tests are
failing.
The downside is that it's now harder to tell which tests the *SAN errors
are related to.
This adds the vcpkg triplets and CMake preset to perform release
builds for distribution. These builds are fully static, and currently
intended to be used for the `js` ESVU release.
In the future, linking everything statically into the final binary is
probably not what we will do for released Ladybird builds. Instead, we
may have a "libladybird.so", which is then linked into the binary. But
this should be fine for `js` for now.
In addition to changing the build-type dependent build directories, we
can take this opportunity to move the vcpkg cache directory to the Build
folder itself. This probably isn't 100% needed, but it ensures that no
leftover artifacts are used from non-dynamic vcpkg builds, and it's also
generally nice to have all build artifacts under Build.
The reason for this change is that CMake/vcpkg are unable to detect a
change to VCPKG_LIBRARY_LINKAGE. So when we switch to dynamic builds,
the switch would be non-functional, and every developer would have to
remove their Build and vcpkg cache directories manually. By changing
these directories, vcpkg is able to detect it must rebuild.
LLVM recommends compiling with at least -O1 to have decent performance
with sanitizers enabled. Indeed, this improves CI performance of LibWeb
tests as follows:
GCC on Linux: 160.61s to 119.68s (40.93s faster)
Clang on Linux: 65.56s to 55.64s ( 9.92s faster)
AK will depend on some vcpkg dependencies, so the Lagom tools build will
need to know how to use vcpkg. We can do this by sym-linking vcpkg.json
to Meta/Lagom (as vcpkg.json has to be in the CMake source directory).
We also need a CMakePresets.json in the source directory, which can just
include the root file. The root CMakePresets then needs to define paths
relative to ${fileDir} rather than ${sourceDir}.
We currently build debug and release versions of vcpkg dependencies. We
will most commonly only need the release version, so let's default to
that to approximately halve our dependency build time.
This changes the Sanitizer configs to build all the vcpkg dependencies
with our specified CFLAGS and CXXFLAGS for ASAN and UBSAN.
Unfortunately, we can't yet enable actually compiling them with
sanitizers enabled, because this causes test failures that need to be
investigated.
By default, we were linking the debug version of all vcpkg dependencies,
which was very noticeable in benchmarks. Let's default to a build type
with reasonable performance.
