2019-11-19 05:18:28 +03:00
|
|
|
#!/bin/bash
|
|
|
|
set -e
|
|
|
|
set +x
|
|
|
|
|
2022-03-04 13:22:28 +03:00
|
|
|
RUST_VERSION="1.57.0"
|
2021-04-20 23:27:57 +03:00
|
|
|
CBINDGEN_VERSION="0.19.0"
|
2020-07-30 19:59:39 +03:00
|
|
|
|
2019-11-20 03:08:27 +03:00
|
|
|
trap "cd $(pwd -P)" EXIT
|
2020-12-05 05:46:20 +03:00
|
|
|
|
2021-08-07 15:32:18 +03:00
|
|
|
cd "$(dirname "$0")"
|
2020-12-05 05:46:20 +03:00
|
|
|
SCRIPT_FOLDER="$(pwd -P)"
|
2021-07-14 04:12:53 +03:00
|
|
|
source "${SCRIPT_FOLDER}/../utils.sh"
|
2020-12-05 05:46:20 +03:00
|
|
|
|
|
|
|
if [[ ! -z "${FF_CHECKOUT_PATH}" ]]; then
|
|
|
|
cd "${FF_CHECKOUT_PATH}"
|
|
|
|
echo "WARNING: checkout path from FF_CHECKOUT_PATH env: ${FF_CHECKOUT_PATH}"
|
|
|
|
else
|
2021-10-14 20:20:06 +03:00
|
|
|
cd "$HOME/firefox"
|
2020-12-05 05:46:20 +03:00
|
|
|
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
|
|
|
|
2022-04-22 22:35:35 +03:00
|
|
|
if is_mac; then
|
2021-07-14 04:12:53 +03:00
|
|
|
CURRENT_HOST_OS_VERSION=$(getMacVersion)
|
2021-10-08 23:05:32 +03:00
|
|
|
# As of Oct 2021, building Firefox requires XCode 13
|
2021-12-10 22:46:10 +03:00
|
|
|
if [[ "${CURRENT_HOST_OS_VERSION}" != "10."* ]]; then
|
2022-03-15 20:44:53 +03:00
|
|
|
selectXcodeVersionOrDie "13.2"
|
2020-06-10 08:48:10 +03:00
|
|
|
else
|
2021-07-14 04:12:53 +03:00
|
|
|
echo "ERROR: ${CURRENT_HOST_OS_VERSION} is not supported"
|
|
|
|
exit 1
|
|
|
|
fi
|
2019-11-19 05:18:28 +03:00
|
|
|
echo "-- building on Mac"
|
2022-04-22 22:35:35 +03:00
|
|
|
elif is_linux; then
|
2019-11-19 05:18:28 +03:00
|
|
|
echo "-- building on Linux"
|
2022-04-22 22:35:35 +03:00
|
|
|
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
|
2022-01-27 04:29:53 +03:00
|
|
|
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
|
|
|
|
2022-04-01 01:09:38 +03:00
|
|
|
echo "-- building on Windows"
|
2021-10-28 03:20:23 +03:00
|
|
|
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')
|
2020-11-06 03:51:42 +03:00
|
|
|
WIN32_REDIST_DIR=$(dirname "$DLL_FILE")
|
2020-11-06 00:56:15 +03:00
|
|
|
if ! [[ -d $WIN32_REDIST_DIR ]]; then
|
2020-11-06 03:51:42 +03:00
|
|
|
echo "ERROR: cannot find MS VS C++ redistributable $WIN32_REDIST_DIR"
|
2020-11-06 00:56:15 +03:00
|
|
|
exit 1;
|
|
|
|
fi
|
2019-11-19 05:18:28 +03:00
|
|
|
else
|
|
|
|
echo "ERROR: cannot upload on this platform!" 1>&2
|
|
|
|
exit 1;
|
|
|
|
fi
|
|
|
|
|
2021-11-05 22:15:34 +03:00
|
|
|
if [[ $1 == "--linux-arm64" || $2 == "--linux-arm64" ]]; then
|
|
|
|
echo "ac_add_options --target=aarch64-linux-gnu" >> .mozconfig
|
|
|
|
fi
|
|
|
|
|
2020-03-21 05:24:38 +03:00
|
|
|
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
|
2021-09-08 16:15:22 +03:00
|
|
|
echo "ac_add_options --disable-backgroundtasks" >> .mozconfig
|
|
|
|
|
2021-10-16 00:48:50 +03:00
|
|
|
if [[ -n $FF_DEBUG_BUILD ]]; then
|
|
|
|
echo "ac_add_options --enable-debug" >> .mozconfig
|
2021-12-15 19:31:33 +03:00
|
|
|
echo "ac_add_options --enable-debug-symbols" >> .mozconfig
|
|
|
|
else
|
|
|
|
echo "ac_add_options --enable-release" >> .mozconfig
|
2021-10-16 00:48:50 +03:00
|
|
|
fi
|
|
|
|
|
2022-04-22 22:35:35 +03:00
|
|
|
if is_win || is_mac; then
|
2021-09-08 16:15:22 +03:00
|
|
|
# This options is only available on win and mac.
|
|
|
|
echo "ac_add_options --disable-update-agent" >> .mozconfig
|
|
|
|
fi
|
2020-03-21 05:24:38 +03:00
|
|
|
|
2021-08-06 20:16:14 +03:00
|
|
|
if [[ $1 != "--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
|
|
|
|
|
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
|
2022-04-22 22:35:35 +03:00
|
|
|
if is_linux; then
|
2021-12-14 11:49:35 +03:00
|
|
|
echo "ac_add_options --enable-bootstrap" >> .mozconfig
|
2021-12-16 04:14:08 +03:00
|
|
|
SHELL=/bin/sh ./mach --no-interactive bootstrap --application-choice=browser
|
2021-12-14 11:49:35 +03:00
|
|
|
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
|
2021-02-03 08:35:12 +03:00
|
|
|
fi
|
|
|
|
|
2022-04-22 22:35:35 +03:00
|
|
|
if is_mac; then
|
2021-12-15 19:31:33 +03:00
|
|
|
if [[ ! -d "$HOME/.mozbuild/clang" ]]; then
|
|
|
|
echo "ERROR: build toolchains are not found, specifically \$HOME/.mozbuild/clang is not there!"
|
|
|
|
echo "Since December, 2021, build toolchains have to be predownloaded (see https://github.com/microsoft/playwright/pull/10929)"
|
|
|
|
echo
|
|
|
|
echo "To bootstrap toolchains:"
|
|
|
|
echo " ./browser_patches/prepare_checkout.sh firefox-beta"
|
|
|
|
echo " ./browser_patches/build.sh firefox-beta --bootstrap"
|
|
|
|
echo
|
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
export MOZ_AUTOMATION=1
|
|
|
|
export MOZ_FETCHES_DIR=$HOME/.mozbuild
|
|
|
|
fi
|
|
|
|
|
2020-06-05 00:26:51 +03:00
|
|
|
if [[ $1 == "--juggler" ]]; then
|
|
|
|
./mach build faster
|
2021-09-13 18:01:35 +03:00
|
|
|
else
|
|
|
|
./mach build
|
2022-04-22 22:35:35 +03:00
|
|
|
if is_mac; then
|
2022-03-04 13:22:28 +03:00
|
|
|
node "${SCRIPT_FOLDER}"/install-preferences.js "$PWD"/${OBJ_FOLDER}/dist
|
|
|
|
else
|
|
|
|
node "${SCRIPT_FOLDER}"/install-preferences.js "$PWD"/${OBJ_FOLDER}/dist/bin
|
|
|
|
fi
|
2020-06-05 00:26:51 +03:00
|
|
|
fi
|
2020-02-12 03:22:31 +03:00
|
|
|
|
2020-02-12 01:32:15 +03:00
|
|
|
|