2019-11-19 05:18:28 +03:00
|
|
|
#!/bin/bash
|
|
|
|
set -e
|
|
|
|
set +x
|
|
|
|
|
2021-08-11 16:01:52 +03:00
|
|
|
RUST_VERSION="1.51.0"
|
2021-04-20 23:27:57 +03:00
|
|
|
CBINDGEN_VERSION="0.19.0"
|
2020-12-16 03:27:34 +03:00
|
|
|
# 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"
|
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-07-14 19:26:43 +03:00
|
|
|
cd "../firefox/checkout"
|
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
|
|
|
|
2019-11-19 05:18:28 +03:00
|
|
|
if [[ "$(uname)" == "Darwin" ]]; 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-10-08 02:23:00 +03:00
|
|
|
if [[ "${CURRENT_HOST_OS_VERSION}" == "11."* ]]; then
|
2021-10-08 23:05:32 +03:00
|
|
|
selectXcodeVersionOrDie "13"
|
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"
|
|
|
|
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
|
|
|
|
|
2020-11-06 03:51:42 +03:00
|
|
|
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
|
2020-12-03 19:09:05 +03:00
|
|
|
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"
|
2020-12-03 19:09:05 +03:00
|
|
|
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
|
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
|
|
|
|
|
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
|
|
|
|
|
|
|
|
if [[ "$(uname)" == MINGW* || "$(uname)" == "Darwin" ]]; then
|
|
|
|
# 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
|
2021-07-14 19:26:43 +03:00
|
|
|
if [[ "$(uname)" == "Darwin" || "$(uname)" == "Linux" ]]; then
|
2021-05-20 01:16:33 +03:00
|
|
|
SHELL=/bin/sh ./mach --no-interactive bootstrap --application-choice=browser
|
2021-02-03 08:53:23 +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
|
|
|
|
|
2020-10-08 00:34:58 +03:00
|
|
|
if ! [[ -f "$HOME/.mozbuild/_virtualenvs/mach/bin/python" ]]; then
|
|
|
|
./mach create-mach-environment
|
|
|
|
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
|
2020-06-05 00:26:51 +03:00
|
|
|
fi
|
2020-02-12 03:22:31 +03:00
|
|
|
|
|
|
|
if [[ "$(uname)" == "Darwin" ]]; then
|
2021-08-07 15:32:18 +03:00
|
|
|
node "${SCRIPT_FOLDER}"/install-preferences.js "$PWD"/${OBJ_FOLDER}/dist
|
2020-02-12 03:22:31 +03:00
|
|
|
else
|
2021-08-07 15:32:18 +03:00
|
|
|
node "${SCRIPT_FOLDER}"/install-preferences.js "$PWD"/${OBJ_FOLDER}/dist/bin
|
2020-02-12 03:22:31 +03:00
|
|
|
fi
|
2020-02-12 01:32:15 +03:00
|
|
|
|