playwright/browser_patches/firefox/build.sh

185 lines
5.3 KiB
Bash
Raw Normal View History

2019-11-19 05:18:28 +03:00
#!/bin/bash
set -e
set +x
RUST_VERSION="1.59.0"
CBINDGEN_VERSION="0.23.0"
2019-11-20 03:08:27 +03:00
trap "cd $(pwd -P)" EXIT
cd "$(dirname "$0")"
SCRIPT_FOLDER="$(pwd -P)"
source "${SCRIPT_FOLDER}/../utils.sh"
if [[ ! -z "${FF_CHECKOUT_PATH}" ]]; then
cd "${FF_CHECKOUT_PATH}"
echo "WARNING: checkout path from FF_CHECKOUT_PATH env: ${FF_CHECKOUT_PATH}"
else
cd "$HOME/firefox"
fi
args=("$@")
IS_FULL=""
IS_JUGGLER=""
IS_LINUX_ARM64=""
IS_DEBUG=""
for ((i="${#args[@]}"-1; i >= 0; --i)); do
case ${args[i]} in
--full) IS_FULL="1"; unset args[i]; ;;
--juggler) IS_JUGGLER="1"; unset args[i]; ;;
--linux-arm64) IS_LINUX_ARM64="1"; unset args[i]; ;;
--debug) IS_DEBUG="1"; unset args[i]; ;;
esac
done
if [[ -n "${IS_JUGGLER}" && -n "${IS_FULL}" ]]; then
echo "ERROR: either --full or --juggler is allowed"
exit 1
fi
echo "== BUILD CONFIGURATION =="
if [[ -n "${IS_FULL}" ]]; then
echo "- build type: FULL"
elif [[ -n "${IS_JUGGLER}" ]]; then
echo "- build type: JUGGLER"
else
echo "- build type: INCREMENTAL"
fi
if [[ -n "${IS_DEBUG}" ]]; then
echo "- debug: YES"
else
echo "- debug: NO"
fi
if [[ -n "${IS_LINUX_ARM64}" ]]; then
echo "- linux aarch64: YES"
else
echo "- linux aarch64: NO"
fi
echo "========================="
2021-02-19 21:52:12 +03:00
rm -rf .mozconfig
browser(firefox): properly initialize debugging pipe on windows (#5514) browser(firefox): properly initialize debugging pipe on windows Firefox on Windows has 2 launch modes: - default: a special "launcher process" is used to start browser as a sub-process - non-default: browser process starts right away Firefox has a logic to detect how successful was the use of the launcher process to do self-recovery when things go wrong. Namely: - when attempting to use launcher process, firefox records a timestamp of the attempt beginning - once the launcher process successfully launches browser sub-process, firefox records another timestamp of the completion On a new launch, firefox checks what timestamps are present. If there's a timestamp that signifies start of launcher process, but no successful timestamp, it decides that last "launcher process" use was not successful and falls back to launching browser right away. When launching 2 firefox processes right away, the first process uses attempts to use launcher process and records the first timestamp. At the same time, the second instance sees the first timestamp and doesn't see the second timestamp, and falls back to launching browser right away. Our debugging pipe code, however, does not support non-launcher-process code path. This patch adds support for remote debugging pipe in case of non-launcher-process startup. Drive-by: - disable crashreporter altogether - remove stray dcheck that breaks firefox debug compilation - disable compilation of firefox update agent - do not use WIN32_DISTRIB flag unless doing full builds since it kills incremental compilation References #4660
2021-02-19 21:32:47 +03:00
if is_mac; then
selectXcodeVersionOrDie $(node "${SCRIPT_FOLDER}/../get_xcode_version.js" firefox)
2019-11-19 05:18:28 +03:00
echo "-- building on Mac"
elif is_linux; then
2019-11-19 05:18:28 +03:00
echo "-- building on Linux"
elif is_win; then
browser(firefox): properly initialize debugging pipe on windows (#5514) browser(firefox): properly initialize debugging pipe on windows Firefox on Windows has 2 launch modes: - default: a special "launcher process" is used to start browser as a sub-process - non-default: browser process starts right away Firefox has a logic to detect how successful was the use of the launcher process to do self-recovery when things go wrong. Namely: - when attempting to use launcher process, firefox records a timestamp of the attempt beginning - once the launcher process successfully launches browser sub-process, firefox records another timestamp of the completion On a new launch, firefox checks what timestamps are present. If there's a timestamp that signifies start of launcher process, but no successful timestamp, it decides that last "launcher process" use was not successful and falls back to launching browser right away. When launching 2 firefox processes right away, the first process uses attempts to use launcher process and records the first timestamp. At the same time, the second instance sees the first timestamp and doesn't see the second timestamp, and falls back to launching browser right away. Our debugging pipe code, however, does not support non-launcher-process code path. This patch adds support for remote debugging pipe in case of non-launcher-process startup. Drive-by: - disable crashreporter altogether - remove stray dcheck that breaks firefox debug compilation - disable compilation of firefox update agent - do not use WIN32_DISTRIB flag unless doing full builds since it kills incremental compilation References #4660
2021-02-19 21:32:47 +03:00
echo "ac_add_options --disable-update-agent" >> .mozconfig
echo "ac_add_options --disable-default-browser-agent" >> .mozconfig
echo "ac_add_options --disable-maintenance-service" >> .mozconfig
browser(firefox): properly initialize debugging pipe on windows (#5514) browser(firefox): properly initialize debugging pipe on windows Firefox on Windows has 2 launch modes: - default: a special "launcher process" is used to start browser as a sub-process - non-default: browser process starts right away Firefox has a logic to detect how successful was the use of the launcher process to do self-recovery when things go wrong. Namely: - when attempting to use launcher process, firefox records a timestamp of the attempt beginning - once the launcher process successfully launches browser sub-process, firefox records another timestamp of the completion On a new launch, firefox checks what timestamps are present. If there's a timestamp that signifies start of launcher process, but no successful timestamp, it decides that last "launcher process" use was not successful and falls back to launching browser right away. When launching 2 firefox processes right away, the first process uses attempts to use launcher process and records the first timestamp. At the same time, the second instance sees the first timestamp and doesn't see the second timestamp, and falls back to launching browser right away. Our debugging pipe code, however, does not support non-launcher-process code path. This patch adds support for remote debugging pipe in case of non-launcher-process startup. Drive-by: - disable crashreporter altogether - remove stray dcheck that breaks firefox debug compilation - disable compilation of firefox update agent - do not use WIN32_DISTRIB flag unless doing full builds since it kills incremental compilation References #4660
2021-02-19 21:32:47 +03:00
echo "-- building win64 build on MINGW"
echo "ac_add_options --target=x86_64-pc-mingw32" >> .mozconfig
echo "ac_add_options --host=x86_64-pc-mingw32" >> .mozconfig
DLL_FILE=$("C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe" -latest -find '**\Redist\MSVC\*\x64\**\vcruntime140.dll')
WIN32_REDIST_DIR=$(dirname "$DLL_FILE")
if ! [[ -d $WIN32_REDIST_DIR ]]; then
echo "ERROR: cannot find MS VS C++ redistributable $WIN32_REDIST_DIR"
exit 1;
fi
2019-11-19 05:18:28 +03:00
else
echo "ERROR: cannot upload on this platform!" 1>&2
exit 1;
fi
if [[ -n "${IS_LINUX_ARM64}" ]]; then
echo "ac_add_options --target=aarch64-linux-gnu" >> .mozconfig
fi
# There's no pre-built wasi sysroot on certain platforms.
echo "ac_add_options --without-wasm-sandboxed-libraries" >> .mozconfig
OBJ_FOLDER="obj-build-playwright"
echo "mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/${OBJ_FOLDER}" >> .mozconfig
browser(firefox): properly initialize debugging pipe on windows (#5514) browser(firefox): properly initialize debugging pipe on windows Firefox on Windows has 2 launch modes: - default: a special "launcher process" is used to start browser as a sub-process - non-default: browser process starts right away Firefox has a logic to detect how successful was the use of the launcher process to do self-recovery when things go wrong. Namely: - when attempting to use launcher process, firefox records a timestamp of the attempt beginning - once the launcher process successfully launches browser sub-process, firefox records another timestamp of the completion On a new launch, firefox checks what timestamps are present. If there's a timestamp that signifies start of launcher process, but no successful timestamp, it decides that last "launcher process" use was not successful and falls back to launching browser right away. When launching 2 firefox processes right away, the first process uses attempts to use launcher process and records the first timestamp. At the same time, the second instance sees the first timestamp and doesn't see the second timestamp, and falls back to launching browser right away. Our debugging pipe code, however, does not support non-launcher-process code path. This patch adds support for remote debugging pipe in case of non-launcher-process startup. Drive-by: - disable crashreporter altogether - remove stray dcheck that breaks firefox debug compilation - disable compilation of firefox update agent - do not use WIN32_DISTRIB flag unless doing full builds since it kills incremental compilation References #4660
2021-02-19 21:32:47 +03:00
echo "ac_add_options --disable-crashreporter" >> .mozconfig
echo "ac_add_options --disable-backgroundtasks" >> .mozconfig
if [[ -n "${IS_DEBUG}" ]]; then
echo "ac_add_options --enable-debug" >> .mozconfig
echo "ac_add_options --enable-debug-symbols" >> .mozconfig
else
echo "ac_add_options --enable-release" >> .mozconfig
fi
if is_mac || is_win; then
# This options is only available on win and mac.
echo "ac_add_options --disable-update-agent" >> .mozconfig
fi
if [[ -z "${IS_JUGGLER}" ]]; then
# TODO: rustup is not in the PATH on Windows
if command -v rustup >/dev/null; then
# We manage Rust version ourselves.
echo "-- Using rust v${RUST_VERSION}"
rustup install "${RUST_VERSION}"
rustup default "${RUST_VERSION}"
fi
# TODO: cargo is not in the PATH on Windows
if command -v cargo >/dev/null; then
echo "-- Using cbindgen v${CBINDGEN_VERSION}"
cargo install cbindgen --version "${CBINDGEN_VERSION}"
fi
fi
if [[ -n "${IS_FULL}" ]]; then
if is_mac; then
echo "ac_add_options --enable-bootstrap" >> .mozconfig
else
# This is a slow but sure way to get all the necessary toolchains.
# However, it will not work if tree is dirty.
# Bail out if git repo is dirty.
if [[ -n $(git status -s --untracked-files=no) ]]; then
echo "ERROR: dirty GIT state - commit everything and re-run the script."
exit 1
fi
# 1. We have a --single-branch checkout, so we have to add a "master" branch and fetch it
git remote set-branches --add browser_upstream master
git fetch browser_upstream master
# 2. Checkout the master branch and run bootstrap from it.
git checkout browser_upstream/master
SHELL=/bin/sh ./mach --no-interactive bootstrap --application-choice=browser
git checkout -
rm -rf "${OBJ_FOLDER}"
fi
if [[ -n "${WIN32_REDIST_DIR}" ]]; then
browser(firefox): properly initialize debugging pipe on windows (#5514) browser(firefox): properly initialize debugging pipe on windows Firefox on Windows has 2 launch modes: - default: a special "launcher process" is used to start browser as a sub-process - non-default: browser process starts right away Firefox has a logic to detect how successful was the use of the launcher process to do self-recovery when things go wrong. Namely: - when attempting to use launcher process, firefox records a timestamp of the attempt beginning - once the launcher process successfully launches browser sub-process, firefox records another timestamp of the completion On a new launch, firefox checks what timestamps are present. If there's a timestamp that signifies start of launcher process, but no successful timestamp, it decides that last "launcher process" use was not successful and falls back to launching browser right away. When launching 2 firefox processes right away, the first process uses attempts to use launcher process and records the first timestamp. At the same time, the second instance sees the first timestamp and doesn't see the second timestamp, and falls back to launching browser right away. Our debugging pipe code, however, does not support non-launcher-process code path. This patch adds support for remote debugging pipe in case of non-launcher-process startup. Drive-by: - disable crashreporter altogether - remove stray dcheck that breaks firefox debug compilation - disable compilation of firefox update agent - do not use WIN32_DISTRIB flag unless doing full builds since it kills incremental compilation References #4660
2021-02-19 21:32:47 +03:00
# Having this option in .mozconfig kills incremental compilation.
echo "export WIN32_REDIST_DIR=\"$WIN32_REDIST_DIR\"" >> .mozconfig
fi
fi
# Remove the cbindgen from mozbuild to rely on the one we install manually.
# See https://github.com/microsoft/playwright/issues/15174
if is_win; then
rm -rf "${USERPROFILE}\\.mozbuild\\cbindgen"
else
rm -rf "${HOME}/.mozbuild/cbindgen"
fi
if [[ -n "${IS_JUGGLER}" ]]; then
./mach build faster
else
export MOZ_AUTOMATION=1
# Use winpaths instead of unix paths on Windows.
# note: 'cygpath' is not available in MozBuild shell.
if is_win; then
export MOZ_FETCHES_DIR="${USERPROFILE}\\.mozbuild"
else
export MOZ_FETCHES_DIR="${HOME}/.mozbuild"
fi
./mach build
if is_mac; then
FF_DEBUG_BUILD="${IS_DEBUG}" node "${SCRIPT_FOLDER}"/install-preferences.js "$PWD"/${OBJ_FOLDER}/dist
else
FF_DEBUG_BUILD="${IS_DEBUG}" node "${SCRIPT_FOLDER}"/install-preferences.js "$PWD"/${OBJ_FOLDER}/dist/bin
fi
fi