We had numerous NiH-based implementations of audio formats and metadata
that we now no longer need because we either don't make use of the code,
or we replaced its implementation by FFmpeg.
This loader supports whatever format libavformat and libavcodec can
handle. Currently only seekable streams are supported, and we still have
some limitations as to the number of channels and sample format.
Plays all non-streaming audio files at:
https://tools.woolyss.com/html5-audio-video-tester/
Rather than checking the avcodec version in CMake, check it using the
avcodec version macros in the only source file that needs to know about
the AVFrame API/ABI change in version 59.24.100. This is friendlier to
other build systems that would rather avoid configure time checks.
This confirmed works on Xcode 16, and Xcode 16.1 Beta 2, with CMake 3.28
or higher.
On linux, the 6.0.0 release from swiftly is still missing my libstdc++
workaround, so it needs a snapshot to work.
When the detected SDK for CMAKE_OSX_SYSROOT and friends has the same
version as your current macOS system version, CMake helpfully doesn't
set CMAKE_OSX_DEPLOYMENT_TARGET. Unfortunately, in this case, swiftc
will default to macOS 10.4, which is absolutely ancient. Grab the target
triple from the -print-target-info JSON when CMAKE_OSX_DEPLOYMENT_TARGET
is not provided at configure time.
You can now build with STYLE_INVALIDATION_DEBUG and get a debug stream
of reasons why style invalidations are happening and where.
I've rewritten this code many times, so instead of throwing it away once
again, I figured we should at least have it behind a flag.
This is only used for CSS style sheets. One case wants it as a String,
and the others don't care, but will in future also want to have the
source as a String.
When trying to use pkgconfig for finding libjxl, the build fails
trying to link the cross-compiler's libc++.
Using this way libjxl also requires hwy library.
Findlibjxl.cmake was taken from SDL_image and altered to include its license.
This project is a part of the Xcode-shipped toolchain on macOS, but
needs built from source on other platforms. However, using the Xcode
version of the framework leads to a bunch of rpath confusion when
trying to link it the expected way. I suspect that there will be a
more intuitive way to link this library from the toolchain when it
stabilizes. So we'll build it everywhere :)
Instead of using a global setting, let's set this per-target. This
prevents conflicts when importing third-party dependencies that do
not tolerate the mode being "default".
At the same time, simplify CMakeLists magic for libraries that want to
include Swift code in the library. The Lib-less name of the library is
now always the module name for the library with any Swift additions,
extensions, etc. All vfs overlays now live in a common location to make
finding them easier from CMake functions. A new pattern is needed for
the Lib-less modules to re-export their Cxx counterparts.
For a long time, we've used two terms, inconsistently:
- "Identifier" is a spec term, but refers to a sequence of alphanumeric
characters, which may or may not be a keyword. (Keywords are a
subset of all identifiers.)
- "ValueID" is entirely non-spec, and is directly called a "keyword" in
the CSS specs.
So to avoid confusion as much as possible, let's align with the spec
terminology. I've attempted to change variable names as well, but
obviously we use Keywords in a lot of places in LibWeb and so I may
have missed some.
One exception is that I've not renamed "valid-identifiers" in
Properties.json... I'd like to combine that and the "valid-types" array
together eventually, so there's no benefit to doing an extra rename
now.
Commit 35392d4d28 moved the
target_*_directories() calls (or rather their include()) before the
target declaration, so they fail because of the undefined target.
We can fix the problem by using global *_directories() instead.
In theory the clang module map should not have absolute paths for the
headers. Other Swift projects seem to use the -ivfsoverlay feature of
clang to work around this, but it seems difficult to get to work.
And modernize the cmake_parse_arguments() call at the top.
Ideally, we would pull these flags from the target we're generating
for, but the current CMake setup makes that prohibitively infeasible.
This ensures that we can get all the proper warnings on/off to get the
same diagnostics and other options when loading C++ headers into the
Swift frontend.
The main incentive is much better performance. We could have gone a bit
further in optimizing the Skia painter to blit glyphs produced by LibGfx
more efficiently from the glyph atlas, but eventually, we also want Skia
to improve correctness.
This change does not completely replace LibGfx in text handling. It's
still used at all stages, including layout, up until display list
replaying.
Override the vcpkg/scripts/detect_compiler behavior of always pulling
$CC and $CXX at the time that vcpkg install is determined to need called
by forcing $ENV{CXX} and $ENV{CC} to our CMake-determined compiler.
This prevents strange behavior such as running the following:
./Meta/ladybird.sh run
make changes...
ninja -C Build/ladybird
Where the second build step would be run without CC or CXX set in the
environment, causing a total cache miss from vcpkg and a full rebuild.
It also helps prevent full rebuilds when an IDE passes a slightly
different compiler to the build step than ladybird.sh.
- `-fstack-protection-strong` enables stack canaries for functions where
addresses of local variables are taken or arrays/structures
containing arrays are allocated on the stack.
- `-fstrict-flex-arrays=2` causes the compiler to only treat arrays with
unknown bounds (`[]`) or zero-length-arrays (`[0]`) as *flexible array
members*, allowing the sanitizers to emit bounds checks for structs
with proper arrays as their last member.
More rigorous options (such as AArch64 pointer authentication, Control
Flow Integrity, _FORTIFY_SOURCE) should be investigated in the future,
however this is a good baseline.
If no header includes the prototype of a function, then it cannot be
used from outside the translation unit it was defined in. In that case,
it should be marked as `static`, in order to avoid possible ODR
problems, unnecessary exported symbols, and allow the compiler to better
optimize those.
If this warning triggers in a function defined in a header, `inline`
needs to be added, otherwise if the header is included in more than one
TU, it will fail to link with a duplicate definition error.
The reason this diff got so big is that Lagom-only code wasn't built
with this flag even in Serenity times.
These used to be enabled in `serenity_compile_options.cmake` for
Serenity builds and were removed in 9b05fb98. This is a slightly more
conservative subset of those, with ones that are enabled by default
omitted.
This should prevent our code quality regressing in the long run.
Trying to build VulkanLoader from source is a giant headache of
unnecessary packages. Every modern distro has vulkan packages, let's
depend on those instead of trying to build something for both wayland
and X11.
