playwright/browser_patches/firefox/build.sh

127 lines
4.5 KiB
Bash
Raw Normal View History

2019-11-19 05:18:28 +03:00
#!/bin/bash
set -e
set +x
RUST_VERSION="1.49.0"
CBINDGEN_VERSION="0.19.0"
# Certain minimal SDK Version is required by firefox
MACOS_SDK_VERSION="10.12"
# XCode version can be determined from https://en.wikipedia.org/wiki/Xcode
XCODE_VERSION_WITH_REQUIRED_SDK_VERSION="8.3.3"
2019-11-20 03:08:27 +03:00
trap "cd $(pwd -P)" EXIT
2019-11-20 03:58:09 +03:00
cd "$(dirname $0)"
SCRIPT_FOLDER="$(pwd -P)"
if [[ ! -z "${FF_CHECKOUT_PATH}" ]]; then
cd "${FF_CHECKOUT_PATH}"
echo "WARNING: checkout path from FF_CHECKOUT_PATH env: ${FF_CHECKOUT_PATH}"
else
cd "checkout"
fi
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
2019-11-19 05:18:28 +03:00
if [[ "$(uname)" == "Darwin" ]]; then
if [[ $(uname -m) == "arm64" ]]; then
# Building on Apple Silicon requires XCode12.2 and does not require any extra SDKs.
if ! [[ -d "/Applications/Xcode12.2.app" ]]; then
echo "As of Jan 2021, building Firefox on Apple Silicon requires XCode 12.2"
echo "Make sure there's an /Applications/Xcode12.2.app"
echo "Download XCode from https://developer.apple.com/download/more/"
echo ""
exit 1
fi
export DEVELOPER_DIR=/Applications/Xcode12.2.app/Contents/Developer
else
# Firefox currently does not build on 10.15 out of the box - it requires SDK for 10.12.
# Make sure the SDK is out there.
if ! [[ -d $HOME/SDK-archive/MacOSX${MACOS_SDK_VERSION}.sdk ]]; then
echo "As of Dec 2020, Firefox does not build on Mac without ${MACOS_SDK_VERSION} SDK."
echo "Download XCode ${XCODE_VERSION_WITH_REQUIRED_SDK_VERSION} from https://developer.apple.com/download/more/ and"
echo "extract SDK to $HOME/SDK-archive/MacOSX${MACOS_SDK_VERSION}.sdk"
echo ""
echo "More info: https://firefox-source-docs.mozilla.org/setup/macos_build.html"
exit 1
else
echo "-- configuting .mozconfig with ${MACOS_SDK_VERSION} SDK path"
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 --with-macos-sdk=$HOME/SDK-archive/MacOSX${MACOS_SDK_VERSION}.sdk/" >> .mozconfig
fi
2019-11-19 05:18:28 +03:00
fi
echo "-- building on Mac"
elif [[ "$(uname)" == "Linux" ]]; then
echo "-- building on Linux"
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-av1" >> .mozconfig
2019-11-23 02:44:46 +03:00
elif [[ "$(uname)" == MINGW* ]]; 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
DLL_FILE=""
2019-11-23 07:49:40 +03:00
if [[ $1 == "--win64" ]]; then
echo "-- building win64 build on MINGW"
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 --target=x86_64-pc-mingw32" >> .mozconfig
2019-11-23 07:49:40 +03:00
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')
2019-11-23 07:49:40 +03:00
else
echo "-- building win32 build on MINGW"
DLL_FILE=$("C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe" -latest -find '**\Redist\MSVC\*\x86\**\vcruntime140.dll')
2019-11-23 07:49:40 +03:00
fi
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
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
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 [[ $1 == "--full" || $2 == "--full" ]]; then
if [[ "$(uname)" == "Darwin" && "$(uname -m)" == "arm64" ]]; then
./mach artifact toolchain --from-build macosx64-node
rm -rf "$HOME/.mozbuild/node"
mv node "$HOME/.mozbuild/"
elif [[ "$(uname)" == "Darwin" || "$(uname)" == "Linux" ]]; then
SHELL=/bin/sh ./mach --no-interactive bootstrap --application-choice=browser --no-system-changes
fi
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 [[ ! -z "${WIN32_REDIST_DIR}" ]]; then
# Having this option in .mozconfig kills incremental compilation.
echo "export WIN32_REDIST_DIR=\"$WIN32_REDIST_DIR\"" >> .mozconfig
fi
fi
if ! [[ -f "$HOME/.mozbuild/_virtualenvs/mach/bin/python" ]]; then
./mach create-mach-environment
fi
if [[ $1 == "--juggler" ]]; then
./mach build faster
else
# TODO: rustup is not in the PATH on Windows
if command -v rustup >/dev/null; then
2020-07-30 21:50:52 +03:00
# We manage Rust version ourselves.
echo "-- Using rust v${RUST_VERSION}"
rustup install "${RUST_VERSION}"
2020-07-30 21:50:52 +03:00
rustup default "${RUST_VERSION}"
fi
2020-07-30 21:50:52 +03:00
# 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
./mach build
fi
if [[ "$(uname)" == "Darwin" ]]; then
node "${SCRIPT_FOLDER}"/install-preferences.js $PWD/${OBJ_FOLDER}/dist
else
node "${SCRIPT_FOLDER}"/install-preferences.js $PWD/${OBJ_FOLDER}/dist/bin
fi