
FFmpeg hasn't been rolled since [1] in order to avoid to break MSVC trybots (//third_party/ffmpeg dropped MSVC support, in theory it is possible to bring the support back but some work is needed every time //third_party/ffmpeg gets updated). Not rolling //third_party/ffmpeg is not enough to keep the Chromium Roll working because -Wstring-plus-int becomes more chatty with clang 350768 and it has been suppressed in //third_party/ffmpeg/BUILD.gn [2]. Since WebRTC needs to update clang, //third_party/ffmpeg needs to be updated. The only way to do it without fixing MSVC errors in //third_party/ffmpeg is to enforce rtc_use_h264=False when MSVC is used. PSA: https://groups.google.com/forum/#!topic/discuss-webrtc/cfkPPq5nvNE. [1] - https://webrtc-review.googlesource.com/78402 [2] - https://chromium-review.googlesource.com/c/chromium/third_party/ffmpeg/+/1376376 Bug: webrtc:9213 Change-Id: I36bd7fb2db21012760e4ff7a791d81350e402ec0 Reviewed-on: https://webrtc-review.googlesource.com/c/116982 Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org> Reviewed-by: Erik Språng <sprang@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org> Reviewed-by: Oleh Prypin <oprypin@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26257}
MB - The Meta-Build wrapper
MB is a simple wrapper intended to provide a uniform interface to either GYP or GN, such that users and bots can call one script and not need to worry about whether a given bot is meant to use GN or GYP.
It supports two main functions:
-
"gen" - the main
gyp_chromium
/gn gen
invocation that generates the Ninja files needed for the build. -
"analyze" - the step that takes a list of modified files and a list of desired targets and reports which targets will need to be rebuilt.
We also use MB as a forcing function to collect all of the different
build configurations that we actually support for Chromium builds into
one place, in //tools/mb/mb_config.pyl
.
For more information, see: