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.
Prior to this change, running ./Meta/ladybird.sh rebuild would not
remove the user-variables.cmake file that was generated by the build
script. This caused errors when testing out the .devcontainer on my
Mac because the pkg-config binary lived in different dirs in the
container vs host.debug
Between WPT.sh and ladybird.sh.
This is useful to me as I set my default build configuration to Debug,
and have been hacking around with the WPT script to align with this
configuration.
ladybird.sh allows the source directory to be overriden to point to
another source directory. I am not sure if anyone is actually using this
behaviour in practise, but let's make the behaviour at least common
between the two scripts with a helper function.
Previously, using `ladybird.sh run` with any target that was part of the
MacOS app bundle would try to run the given executable from the wrong
directory.
CMake reads CMakePresets.json, which is before it reads CMakeLists.txt.
This causes CMake Error: Unrecognized "version" field if the version of
CMake is older than support for presets, or the version field of
presets.
The fix is to check CMake version in ladybird.sh before trying to create
the build directory.
Co-Authored-By: Andrew Kaster <andrew@ladybird.org>
We need to avoid using vcpkg's pkg-config on non-x86_64 platforms,
because they do very strange things to the default paths.
On Asahi Linux and other 16 KiB page distros, the user must also provide
a properly compiled version of GN.
Also add a vcpkg command to ladybird.sh to ensure that vcpkg is setup,
and use a local binary cache for vcpkg build and install media to
avoid cluttering $XDG_CACHE_HOME.
And hook it into ladybird.sh for convenience. The script will set up
PATH and other environment variables automatically.
On CI, vcpkg is theoretically already installed on Linux machines, but
not with the right environment variables, and not on macOS. So this also
makes CI use this script to bootstrap vcpkg.