The function currently has 2 purposes: (1) To copy dependent dlls for
executables to output binary directory. This ensures that these helper
processes can be ran after a build given not all DLLs from vcpkg libs
get implicitly copied to the bin folder. (2) Allow fully background
and/or GUI processes to use the Windows Subsystem. This prevents
unnecessarily launching a console for the process, as we either require
no user interaction or the user interaction is all handled in the GUI.
This commit replaces the default backtrace logic with cpptrace, for
nicer, colored backtraces. Cpptrace runs on all of our supported
platforms excpet android. As such backtrace.h is left in place.
All the backtrace functions are made noinline to have a consistent
number of frames. A maximum depth parameter is added to dump_backtrace
with a default of 100. This should be enough, and can be easily
changed, and allows for limiting the maximum depth.
Setting the LADYBIRD_BACKTRACE_SNIPPETS environment variable enables
surrouding code snippets in the backtrace. Specifically 2 lines above
and below. This number can be changed by calling snippet_context on the
formatter. For the whole list of options of what can be done with
formatting see the cpptrace repository.
On Windows we skipped frames when verification fails and when
dump_backtrace was added the logic was wrong and would have skipped
frames we care about.
This commit also implements skipping frames on Linux.
The only time where this does not skip all frames is when the call to
backtrace gets intercepted. Then we will end up skipping one frame less
than needed.
To keep delayload on Windows a patch and overlay port is used. When
upstream accepts these changes and vcpkg bumps the version the patch
could be removed to have just the cmake define.
The current HEAD contains a bunch of stuff not supported by wabt (or
us), that also appear to not be fully merged yet; stick to the last
known commit for now.
We currently have the issue that our macOS builds are being hosted by
both Apple M1 and M4 runners. By default, these target `-mcpu=apple-m1`
and `-mcpu=apple-m3` respectively, causing their ccache artifacts to be
incompatible and effectively thrashing each other's ccache cache on each
run.
Add a new CMake option `ENABLE_CI_BASELINE_CPU` that toggles a baseline
`-mcpu/-march` compile option for each of the supported build platforms.
When disabled (the default), we now default to `-march=native` which on
Linux could theoretically lead to better performance.
The new CPU baseline is used by the `lagom-template.yml` and
`js-and-wasm-artifacts.yml` workflows, since they both produce artifacts
or caches that might be picked up by other runners. We also enable it
for Flatpak builds, so they target a fixed architecture instead of
whatever architecture the action runner that picked up the job has.
Generating boilerplate is nice! This also has the bonus that we're more
correct: I included all the units listed in the spec before,
(see https://drafts.css-houdini.org/css-typed-om-1/#numeric-factory )
but we're supposed to exactly include ones for the units we support:
> If an implementation supports additional CSS units that do not have a
corresponding method in the above list, but that do correspond to one
of the existing CSSNumericType values, it must additionally support
such a method, named after the unit in its defined canonical casing,
using the generic behavior defined above.
> If an implementation does not support a given unit, it must not
implement its corresponding method from the list above.
Now, our factory functions will exactly match the units we support.
The changed test result is partly the order being different, and partly
that the container-query units are no longer included as we don't
actually support them.
The BUILD_RPATH/INSTALL_RPATH CMake infrastructure is not supported
on Windows, but we want to ensure Ladybird executables are runnable
after the build phase so there can be an efficient dev loop.
lagom_copy_runtime_dlls() can be used by executable targets so all
their dependent dlls are copied to their output directory in their
post build step.
flatpak-builder doesn't respect .gitignore when creating its local build
directory, so we need to explicitly skip potentially large ignored
directories to avoid bloating the flatpak build directory during builds.
We now clean up installed helper tools, includes from dependencies, and
pkgconfig/CMake files. This decreases the size of the flatpak from
~206MiB to ~150 MiB on my machine.
The manifest is also mostly clean of linter warnings from the
flatpack-builder manifest linter, with the exception of the overly broad
session bus policy.
The docs at https://docs.flathub.org/docs/for-app-authors/linter list a
method for selecting the correct session bus policies, but it is unclear
how to actually get the full set.
On FreeBSD some symbols like `environ` or `__progname` are not exported
anywhere and are filled in by the dynamic loader. `environ` is
a special case because we make use of it explicitly so we need to mark
it a weak symbol so the linker doesn't complain.
This adds an overlay port for curl that adds the features required for
HTTP/3.
This is not quite compatible with the upstream vcpkg.json, because
enabling HTTP/2 makes it use the default SSL backend, which is
sectransp for macOS and schannel on Windows. These backends are not
compatible with ngtcp2. Additionally, we can not build curl with
multiple SSL backends when using ngtcp2.
I couldn't find a way to selectively disable/enable dependencies based
on what features are enabled, so I made HTTP/2 pick OpenSSL in our
overlay port. Upstream vcpkg will likely want to support wolfSSL and
GnuTLS backends for ngtcp2, so they'll be additional work to get this
into upstream.
This build depends on the KDE Flatpak SDK, and builds any missing
dependencies manually as source modules.
The flatpak can be built with the following command:
```sh
flatpak-builder --user --force-clean --install-deps-from=flathub \
--ccache --repo=Build/repo --install Build/flatpak \
Meta/CMake/flatpak/org.ladybird.Ladybird.json
```
After building, the flatpak can be run with:
```sh
flatpak run --user --devel org.ladybird.Ladybird
```
If there are issues launching RequestServer, the .pid and .sock files
under $XDG_RUNTIME_DIR may need removed.
```sh
flatpak run --user --command=sh --devel org.ladybird.Ladybird
rm -f $XDG_RUNTIME_DIR/Ladybird.*
```
These files are lifted from the ladybird-gtk4 repository and adapted
to work with the Qt UI port. They are installed by default on Linux, but
can be installed via a CMake option on other platforms.
Co-Authored-By: Sergey Bugaev <bugaevc@serenityos.org>
Co-Authored-By: Nicolas Ramz <nicolas.ramz@adevinta.com>
Co-Authored-By: Beckett Normington <beckett@b0ba.dev>
Co-Authored-By: Xexxa <93391300+Xexxa@users.noreply.github.com>
To support this, how we declare logical property aliases has changed.
Instead of `logical-alias-for` being a list of properties, it's now an
object with a `group` and `mapping`. The group is the name of a logical
property group in LogicalPropertyGroups.json. The mapping is which
side/dimension/corner this property is. Hopefully it's self-explanatory
enough.
The generated code is very much a copy of what was previously in
`StyleComputer::map_logical_alias_to_physical_property_id()`, so there
should be no behaviour change.
We haven't required a local copy of the ca-certificates since switching
to OpenSSL as the backend for TLS. Remove the script to download the
PEM file, and update the tests to use the system's CA certificates.
