diff --git a/Documentation/AdvancedBuildInstructions.md b/Documentation/AdvancedBuildInstructions.md index 57a2bf226c0..2d668e5f8e4 100644 --- a/Documentation/AdvancedBuildInstructions.md +++ b/Documentation/AdvancedBuildInstructions.md @@ -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 `: diff --git a/Documentation/BuildInstructionsLadybird.md b/Documentation/BuildInstructionsLadybird.md index 303103afc70..a2a1197d8a5 100644 --- a/Documentation/BuildInstructionsLadybird.md +++ b/Documentation/BuildInstructionsLadybird.md @@ -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 with `./Meta/ladybird.py run `. ### 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 diff --git a/Documentation/EditorConfiguration/EmacsConfiguration.md b/Documentation/EditorConfiguration/EmacsConfiguration.md index 38445ae7303..0f5a4aa8d4e 100644 --- a/Documentation/EditorConfiguration/EmacsConfiguration.md +++ b/Documentation/EditorConfiguration/EmacsConfiguration.md @@ -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`. diff --git a/Documentation/EditorConfiguration/NvimConfiguration.md b/Documentation/EditorConfiguration/NvimConfiguration.md index 382fd19f4aa..ac4f0af41ea 100644 --- a/Documentation/EditorConfiguration/NvimConfiguration.md +++ b/Documentation/EditorConfiguration/NvimConfiguration.md @@ -6,26 +6,26 @@ 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 -> Note: This guide assumes Lua is being used, but can easily be adapted to +> Note: This guide assumes Lua is being used, but can easily be adapted to > VimScript. If you have an [nvim-lspconfig](https://github.com/neovim/nvim-lspconfig), setup already, registering clangd is similar to other LSPs: ```lua require('lspconfig').clangd.setup { - -- If you have an on_attach function, this is where you'd put it. If not, + -- If you have an on_attach function, this is where you'd put it. If not, -- you can delete this line. -- on_attach = ..., -- This is where you'd put capabilities (i.e. if you're useing nvim-cmp) -- capabilities = ..., - -- If you have another clangd installation, put it here. Note that we use + -- If you have another clangd installation, put it here. Note that we use -- clangd version 18 for the Ladybird project. -- cmd = { '/path/to/clangd' }, } diff --git a/Documentation/EditorConfiguration/VSCodeConfiguration.md b/Documentation/EditorConfiguration/VSCodeConfiguration.md index 4b60b6991bf..4cf51683000 100644 --- a/Documentation/EditorConfiguration/VSCodeConfiguration.md +++ b/Documentation/EditorConfiguration/VSCodeConfiguration.md @@ -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. diff --git a/Documentation/Testing.md b/Documentation/Testing.md index bc3026934ff..f5eeb99de68 100644 --- a/Documentation/Testing.md +++ b/Documentation/Testing.md @@ -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 diff --git a/ISSUES.md b/ISSUES.md index 4c93e328456..480a210bdc0 100644 --- a/ISSUES.md +++ b/ISSUES.md @@ -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 ``` diff --git a/Meta/WPT.sh b/Meta/WPT.sh index fb21db3050e..9407ceac873 100755 --- a/Meta/WPT.sh +++ b/Meta/WPT.sh @@ -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}" diff --git a/Tests/LibWeb/add_libweb_test.py b/Tests/LibWeb/add_libweb_test.py index fe776d55521..7c717c915d5 100755 --- a/Tests/LibWeb/add_libweb_test.py +++ b/Tests/LibWeb/add_libweb_test.py @@ -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 """ diff --git a/UI/Android/BuildLagomTools.sh b/UI/Android/BuildLagomTools.sh index 61955ef0e15..eff8b9d744f 100755 --- a/UI/Android/BuildLagomTools.sh +++ b/UI/Android/BuildLagomTools.sh @@ -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 \