2019-11-19 05:18:28 +03:00
|
|
|
#!/bin/bash
|
|
|
|
set -e
|
|
|
|
set +x
|
|
|
|
|
2021-01-06 02:49:28 +03:00
|
|
|
RUST_VERSION="1.49.0"
|
2021-02-02 02:50:11 +03:00
|
|
|
CBINDGEN_VERSION="0.16.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
|
|
|
|
2019-11-20 03:58:09 +03:00
|
|
|
cd "$(dirname $0)"
|
2020-12-05 05:46:20 +03:00
|
|
|
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
|
2021-01-12 03:57:59 +03:00
|
|
|
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
|
2020-06-10 08:48:10 +03:00
|
|
|
else
|
2021-01-12 03:57:59 +03:00
|
|
|
# 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
|
2021-01-12 03:57:59 +03:00
|
|
|
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
|
|
|
|
|
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
|
2020-03-21 05:24:38 +03:00
|
|
|
|
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-02-03 08:53:23 +03:00
|
|
|
if [[ "$(uname)" == "Darwin" && "$(uname -m)" == "arm64" ]]; then
|
|
|
|
./mach artifact toolchain --from-build macosx64-node
|
2021-02-03 09:59:33 +03:00
|
|
|
rm -rf "$HOME/.mozbuild/node"
|
|
|
|
mv node "$HOME/.mozbuild/"
|
2021-02-03 08:53:23 +03:00
|
|
|
elif [[ "$(uname)" == "Darwin" || "$(uname)" == "Linux" ]]; then
|
|
|
|
SHELL=/bin/sh ./mach bootstrap --application-choice=browser --no-interactive --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
|
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
|
|
|
|
else
|
2020-08-04 10:02:14 +03:00
|
|
|
# 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}"
|
2020-08-19 19:11:28 +03:00
|
|
|
rustup install "${RUST_VERSION}"
|
2020-07-30 21:50:52 +03:00
|
|
|
rustup default "${RUST_VERSION}"
|
|
|
|
fi
|
2020-07-30 19:59:39 +03:00
|
|
|
|
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
|
2020-06-05 00:26:51 +03:00
|
|
|
./mach build
|
|
|
|
fi
|
2020-02-12 03:22:31 +03:00
|
|
|
|
|
|
|
if [[ "$(uname)" == "Darwin" ]]; then
|
2020-12-05 05:46:20 +03:00
|
|
|
node "${SCRIPT_FOLDER}"/install-preferences.js $PWD/${OBJ_FOLDER}/dist
|
2020-02-12 03:22:31 +03:00
|
|
|
else
|
2020-12-05 05:46:20 +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
|
|
|
|