1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-06-07 21:17:07 +09:00

Everywhere: Document use of ladybird.py over ladybird.sh

This commit is contained in:
Timothy Flynn 2025-05-27 18:04:42 -04:00 committed by Tim Flynn
parent 6ac729e03d
commit 7ce88eb4cd
Notes: github-actions[bot] 2025-05-29 23:34:58 +00:00
10 changed files with 38 additions and 38 deletions

View file

@ -4,7 +4,7 @@ This file covers a few advanced scenarios that go beyond what the basic build gu
## Ninja build targets
The `Meta/ladybird.sh` script provides an abstraction over the build targets which are made available by CMake. The
The `Meta/ladybird.py` script provides an abstraction over the build targets which are made available by CMake. The
following build targets cannot be accessed through the script and have to be used directly by changing the current
directory to `Build/release` and then running `ninja <target>`:

View file

@ -172,36 +172,36 @@ Or, download a version of Gradle >= 8.0.0, and run the ``gradlew`` program in ``
## Build steps
### Using ladybird.sh
### Using ladybird.py
The simplest way to build and run ladybird is via the ladybird.sh script:
The simplest way to build and run ladybird is via the ladybird.py script:
```bash
# From /path/to/ladybird
./Meta/ladybird.sh run
./Meta/ladybird.py run
```
On macOS, to build using clang from homebrew:
```bash
CC=$(brew --prefix llvm)/bin/clang CXX=$(brew --prefix llvm)/bin/clang++ ./Meta/ladybird.sh run
CC=$(brew --prefix llvm)/bin/clang CXX=$(brew --prefix llvm)/bin/clang++ ./Meta/ladybird.py run
```
You may also choose to start it in `gdb` using:
```bash
./Meta/ladybird.sh gdb ladybird
./Meta/ladybird.py gdb ladybird
```
The above commands will build a Release version of Ladybird. To instead build a Debug version, run the
`Meta/ladybird.sh` script with the value of the `BUILD_PRESET` environment variable set to `Debug`, like this:
`Meta/ladybird.py` script with the value of the `BUILD_PRESET` environment variable set to `Debug`, like this:
```bash
BUILD_PRESET=Debug ./Meta/ladybird.sh run
BUILD_PRESET=Debug ./Meta/ladybird.py run
```
Note that debug symbols are available in both Release and Debug builds.
If you want to run other applications, such as the headless-browser, the JS REPL, or the WebAssembly REPL, specify an
executable with `./Meta/ladybird.sh run <executable_name>`.
executable with `./Meta/ladybird.py run <executable_name>`.
### The User Interfaces
@ -260,14 +260,14 @@ to CMAKE_INSTALL_PREFIX. If it is not, things will break.
### Custom CMake build directory
The script Meta/ladybird.sh and the default preset in CMakePresets.json both define a build directory of
The script Meta/ladybird.py and the default preset in CMakePresets.json both define a build directory of
`Build/release`. For distribution purposes, or when building multiple configurations, it may be useful to create a custom
CMake build directory.
The install rules in UI/cmake/InstallRules.cmake define which binaries and libraries will be
installed into the configured CMAKE_PREFIX_PATH or path passed to ``cmake --install``.
Note that when using a custom build directory rather than Meta/ladybird.sh, the user may need to provide a suitable C++
Note that when using a custom build directory rather than Meta/ladybird.py, the user may need to provide a suitable C++
compiler (see [Build Prerequisites](BuildInstructionsLadybird.md#build-prerequisites)) via the CMAKE_C_COMPILER and
CMAKE_CXX_COMPILER cmake options.
@ -291,8 +291,8 @@ cmake --preset default -B MyBuildDir -DLAGOM_LINK_POOL_SIZE=2
### Running manually
The Meta/ladybird.sh script will execute the `run-ladybird` and `debug-ladybird` custom targets.
If you don't want to use the ladybird.sh script to run the application, you can run the following commands:
The Meta/ladybird.py script will execute the `run-ladybird` and `debug-ladybird` custom targets.
If you don't want to use the ladybird.py script to run the application, you can run the following commands:
To automatically run in gdb:
```
@ -326,7 +326,7 @@ cross-compiling to other platforms.
Ladybird should be built with debug symbols first. This can be done by adding `-DCMAKE_BUILD_TYPE=Debug` to the cmake command line,
or selecting the Build Type Debug in the CLion CMake profile.
After running Ladybird as suggested above with `./Meta/ladybird.sh run ladybird`, you can now in CLion use Run -> Attach to Process to connect. If debugging layout or rendering issues, filter the listing that opens for `WebContent` and attach to that.
After running Ladybird as suggested above with `./Meta/ladybird.py run ladybird`, you can now in CLion use Run -> Attach to Process to connect. If debugging layout or rendering issues, filter the listing that opens for `WebContent` and attach to that.
Now breakpoints, stepping and variable inspection will work.
@ -334,10 +334,10 @@ Now breakpoints, stepping and variable inspection will work.
If all you want to do is use Instruments, then an Xcode project is not required.
Simply run the `ladybird.sh` script as normal, and then make sure to codesign the Ladybird binary with the proper entitlements to allow Instruments to attach to it.
Simply run the `ladybird.py` script as normal, and then make sure to codesign the Ladybird binary with the proper entitlements to allow Instruments to attach to it.
```
./Meta/ladybird.sh build
./Meta/ladybird.py build
ninja -C Build/release apply-debug-entitlements
# or
codesign -s - -v -f --entitlements Meta/debug.plist Build/release/bin/Ladybird.app

View file

@ -6,7 +6,7 @@ Emacs can be configured with `lsp-mode` and `clangd` to work well.
The official clangd extension can be used for C++ comprehension.
Run cmake (`Meta/ladybird.sh run ladybird` or similar) at least once for clangd
Run cmake (`Meta/ladybird.py run ladybird` or similar) at least once for clangd
to work, as doing so will generate the `Build/release/compile_commands.json`
that is needed by `clangd`.

View file

@ -6,7 +6,7 @@ project:
1. With [nvim-lspconfig](https://github.com/neovim/nvim-lspconfig) (assumes existing setup)
2. With [coc.nvim](https://github.com/neoclide/coc.nvim) (from scratch, potentially out of date)
For both setups, make sure you ran `./Meta/ladybird.sh run ladybird` at least
For both setups, make sure you ran `./Meta/ladybird.py run ladybird` at least
once.
## With nvim-lspconfig

View file

@ -12,7 +12,7 @@ The recommended extensions for VS Code include:
## Configuration
Run `./Meta/ladybird.sh build` at least once to kick off downloading and building vcpkg dependencies.
Run `./Meta/ladybird.py build` at least once to kick off downloading and building vcpkg dependencies.
The CMake Tools plugin should automatically detect the `CMakePresets.json` at the root of the repository.
Selecting and activating the `default` preset should be enough to get started after the initial build.
@ -30,7 +30,7 @@ The official clangd extension can be used for C++ comprehension. It is recommend
clangd uses ``compile_commands.json`` files to understand the project. CMake will generate these in Build/release.
Run ``./Meta/ladybird.sh run ladybird`` at least once to generate the ``compile_commands.json`` file.
Run ``./Meta/ladybird.py run ladybird`` at least once to generate the ``compile_commands.json`` file.
#### Known issues
@ -170,7 +170,7 @@ The following three example tasks should suffice in most situations, and allow y
],
"args": [
"-c",
"\"Meta/ladybird.sh build\""
"\"Meta/ladybird.py build\""
],
"presentation": {
"echo": true,
@ -188,7 +188,7 @@ The following three example tasks should suffice in most situations, and allow y
"command": "bash",
"args": [
"-c",
"Meta/ladybird.sh build"
"Meta/ladybird.py build"
],
"problemMatcher": [
{
@ -225,7 +225,7 @@ The following three example tasks should suffice in most situations, and allow y
"command": "bash",
"args": [
"-c",
"Meta/ladybird.sh run ladybird"
"Meta/ladybird.py run ladybird"
],
"options": {
"env": {
@ -303,7 +303,7 @@ If you want to run the debugger, first place the content below in `.vscode/launc
then run Ladybird with the debug preset and with the `--debug-process WebContent` flag:
```bash
CC=$(brew --prefix llvm)/bin/clang CXX=$(brew --prefix llvm)/bin/clang++ BUILD_PRESET=Debug ./Meta/ladybird.sh run ladybird --debug-process WebContent
CC=$(brew --prefix llvm)/bin/clang CXX=$(brew --prefix llvm)/bin/clang++ BUILD_PRESET=Debug ./Meta/ladybird.py run ladybird --debug-process WebContent
```
Running Ladybird in this way will pause execution until a debugger is attached. You can then run the debugger by going to the **Run and Debug** menu and selecting the **Attach to WebContent** configuration.
@ -329,7 +329,7 @@ For Linux, the `launch.json` will instead be the file below.
Running Ladybird as follows:
```bash
BUILD_PRESET=Debug Meta/ladybird.sh run ladybird --debug-process WebContent
BUILD_PRESET=Debug Meta/ladybird.py run ladybird --debug-process WebContent
```
Then follow the same steps found in the Mac section. Notice also that you need to have `gdb` (the GNU Debugger) installed.

View file

@ -11,9 +11,9 @@ Tests of internal C++ code go in their own `TestFoo.cpp` file in `Tests/LibWeb`.
> [!NOTE]
> To reproduce a CI failure, see the section on [Running with Sanitizers](#running-with-sanitizers).
The easiest way to run tests is to use the `ladybird.sh` script. The LibWeb tests are registered with CMake as a test in
`UI/CMakeLists.txt`. Using the built-in test filtering, you can run all tests with `Meta/ladybird.sh test` or run
just the LibWeb tests with `Meta/ladybird.sh test LibWeb`. The second way is to invoke the headless browser test runner
The easiest way to run tests is to use the `ladybird.py` script. The LibWeb tests are registered with CMake as a test in
`UI/CMakeLists.txt`. Using the built-in test filtering, you can run all tests with `Meta/ladybird.py test` or run
just the LibWeb tests with `Meta/ladybird.py test LibWeb`. The second way is to invoke the headless browser test runner
directly. See the invocation in `UI/CMakeLists.txt` for the expected command line arguments.
A third way is to invoke `ctest` directly. The simplest method is to use the `default` preset from `CMakePresets.json`:
@ -137,14 +137,14 @@ you will need to regenerate the corresponding expectations file to match the act
For Text or Layout tests, you can "rebaseline" the tests to regenerate the expectation file:
```bash
./Meta/ladybird.sh run headless-browser --run-tests "./Tests/LibWeb" --rebaseline -f Text/input/your-new-test-name.html
./Meta/ladybird.py run headless-browser --run-tests "./Tests/LibWeb" --rebaseline -f Text/input/your-new-test-name.html
```
For Ref and Screenshot tests, you will need to supply the equivalently rendering HTML manually. Though for Screenshot
tests, you can generate the reference screenshot itself by running headless-browser in test mode:
```bash
./Meta/ladybird.sh run headless-browser --layout-test-mode Tests/LibWeb/Screenshot/input/your-new-test-name.html --screenshot-path Tests/LibWeb/Screenshot/images/your-new-test-name.png
./Meta/ladybird.py run headless-browser --layout-test-mode Tests/LibWeb/Screenshot/input/your-new-test-name.html --screenshot-path Tests/LibWeb/Screenshot/images/your-new-test-name.png
```
### Text tests

View file

@ -72,5 +72,5 @@ That will give you a URL which you can then include in the issue you raise for t
When investigating a bug, it can be helpful to use the `--enable-idl-tracing` command-line flag when running Ladybird. This will output detailed information about the calls being made to the browser's internal interfaces, which can help pinpoint where a problem is occurring.
```bash
./Meta/ladybird.sh run ladybird --enable-idl-tracing
./Meta/ladybird.py run ladybird --enable-idl-tracing
```

View file

@ -243,7 +243,7 @@ ensure_wpt_repository() {
}
build_ladybird_and_webdriver() {
"${DIR}"/ladybird.sh build WebDriver
"${DIR}"/ladybird.py build WebDriver
}
update_wpt() {
@ -597,7 +597,7 @@ import_wpt()
done < <(printf "%s\n" "${RAW_TESTS[@]}" | sort -u)
pushd "${LADYBIRD_SOURCE_DIR}" > /dev/null
./Meta/ladybird.sh build headless-browser
./Meta/ladybird.py build headless-browser
set +e
for path in "${TESTS[@]}"; do
echo "Importing test from ${path}"

View file

@ -86,7 +86,7 @@ def create_test(test_name: str, test_type: str, is_async: bool = False) -> None:
elif test_type == "Layout":
input_boilerplate = generic_boilerplate
expected_boilerplate = f"""run
./Meta/ladybird.sh run headless-browser --run-tests
./Meta/ladybird.py run headless-browser --run-tests
"${{LADYBIRD_SOURCE_DIR}}/Tests/LibWeb" --rebaseline -f {input_file}
to produce the expected output for this test
"""

View file

@ -27,7 +27,7 @@ CACHE_DIR=${CACHE_DIR:-"${BUILD_DIR}/caches"}
# (And this also works on macOS, despite the fact that $XDG_CACHE_HOME is a Linux-ism.)
export XDG_CACHE_HOME="$CACHE_DIR"
"$LADYBIRD_SOURCE_DIR"/Meta/ladybird.sh vcpkg
"$LADYBIRD_SOURCE_DIR"/Meta/ladybird.py vcpkg
cmake -S "${LADYBIRD_SOURCE_DIR}/Meta/Lagom" -B "$BUILD_DIR/lagom-tools" \
-GNinja -Dpackage=LagomTools \