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

Author: https://github.com/trflynn89
Commit: 7ce88eb4cd
Pull-request: https://github.com/LadybirdBrowser/ladybird/pull/4904
Reviewed-by: https://github.com/ADKaster

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 <target>`:
 

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_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.
+The Meta/ladybird.py 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:
+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

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`.
 

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' },
 }

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.

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
+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.sh test` or run
+`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.sh test LibWeb`. The second way is to invoke the headless browser test runner
+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

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
 ```

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}"

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
 """

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 \