When we use relativized include dir, /showIncludes shows relativized
path for the files in include dir.
This is an effort of removing absolute path from compiling output.
Bug: 439949
Change-Id: I056cd8bb08c10f01855ef3bdb56ea1bcce1b769b
Reviewed-on: https://chromium-review.googlesource.com/1075947
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#562599}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: bed53c80fd3aa103d419bae8523beddbd89d679f
This reverts commit 18da5f23138a86e9142cbebc5b0ef44291d9569a.
Reason for revert: The original commit broke the CFI bot with errors like:
src/native_client/toolchain/linux_x86/pnacl_newlib/bin/../x86_64-nacl/bin/ld:
unrecognized option '--color-diagnostics'
I do not know why this only happened on the CFI bot (XXX), but since we only add
-fuse-ld=lld if !is_nacl, we should set use_lld to false in the nacl toolchains,
which fixes this, and probably many future issues like it.
Original change's description:
> Revert "Let lld emit colored diagnostics when invoked from ninja."
>
> This reverts commit 00db3ddc4c4f9ebd4d95ad44ea4ef74415c66394.
>
> Reason for revert: Breaks Linux CFI build here: https://ci.chromium.org/buildbot/chromium.memory/Linux%20CFI/8024
>
> Original change's description:
> > Let lld emit colored diagnostics when invoked from ninja.
> >
> > Bug: 841221
> > Change-Id: I72d13c78a2c623865a4f29542d25f6b3488b350b
> > Reviewed-on: https://chromium-review.googlesource.com/1067460
> > Reviewed-by: Reid Kleckner <rnk@chromium.org>
> > Commit-Queue: Nico Weber <thakis@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#560343}
>
> TBR=thakis@chromium.org,rnk@chromium.org
>
> Change-Id: I3811083daa622dca605ca32be5cc4c7098b60b4a
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: 841221
> Reviewed-on: https://chromium-review.googlesource.com/1067949
> Reviewed-by: Tommy Li <tommycli@chromium.org>
> Commit-Queue: Tommy Li <tommycli@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#560345}
TBR=thakis@chromium.org,rnk@chromium.org,tommycli@chromium.org
Change-Id: I5d4c9298e3613ab84650f081a59715880d780805
Bug: 841221
Reviewed-on: https://chromium-review.googlesource.com/1068218
Commit-Queue: Reid Kleckner <rnk@chromium.org>
Reviewed-by: Reid Kleckner <rnk@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#560676}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 979ca1f97abdc13a5bd9605ca5bfd21cae211c42
This is a reland of 5a7f3c442684be5eeb244b904bbfc8e6edaf6fda
goma now supports this compiler and the new warnings were dealt with.
Original change's description:
> Switch to VS 2017 15.7.1 with 10.0.17134.0 SDK
>
> This change switches the VS 2017 package to use VS 2017 Update 7.1 while
> using the 10.0.17134.12 SDK. The new SDK is needed to support new HDR
> features, and to stop forcing external developers to install an old
> ([Spring] Creators Update) SDK. This change will also bring in a new
> linker and other build tools, but the version of clang-cl will be
> unchanged.
>
> Packaging was done on a Windows Server 2016 VM, cleanly created for this
> purpose.
>
> Compiler was packaged up by downloading VS 2017 Update 7.1, from
> https://www.visualstudio.com/vs/, and then passing these parameters to
> the installer:
>
> --add Microsoft.VisualStudio.Workload.NativeDesktop
> --add Microsoft.VisualStudio.Component.VC.ATLMFC --includeRecommended
> --passive
>
> Then Add or Remove Programs was used to modify the 10.0.17134.0 SDK to add
> the Debuggers package.
>
> Then the packaging script was run like this:
>
> python depot_tools\win_toolchain\package_from_installed.py 2017 -w 10.0.17134.0
>
> Bug: 773476
> Change-Id: Ic819f3ae79d7e869227bf33fbb8d202e2f57039b
> Reviewed-on: https://chromium-review.googlesource.com/1054027
> Reviewed-by: Nico Weber <thakis@chromium.org>
> Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#559033}
Bug: 773476,834213
Change-Id: I903158f9dfa604f250010a7047496509f51782e7
Reviewed-on: https://chromium-review.googlesource.com/1066130
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#560002}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 82a5f004e0e52897a6e8bac10490a14fc2845625
This reverts commit 5a7f3c442684be5eeb244b904bbfc8e6edaf6fda.
Reason for revert: this breaks v8's VC++ goma builds, reverting until
goma is updated to support this compiler
Original change's description:
> Switch to VS 2017 15.7.1 with 10.0.17134.0 SDK
>
> This change switches the VS 2017 package to use VS 2017 Update 7.1 while
> using the 10.0.17134.12 SDK. The new SDK is needed to support new HDR
> features, and to stop forcing external developers to install an old
> ([Spring] Creators Update) SDK. This change will also bring in a new
> linker and other build tools, but the version of clang-cl will be
> unchanged.
>
> Packaging was done on a Windows Server 2016 VM, cleanly created for this
> purpose.
>
> Compiler was packaged up by downloading VS 2017 Update 7.1, from
> https://www.visualstudio.com/vs/, and then passing these parameters to
> the installer:
>
> --add Microsoft.VisualStudio.Workload.NativeDesktop
> --add Microsoft.VisualStudio.Component.VC.ATLMFC --includeRecommended
> --passive
>
> Then Add or Remove Programs was used to modify the 10.0.17134.0 SDK to add
> the Debuggers package.
>
> Then the packaging script was run like this:
>
> python depot_tools\win_toolchain\package_from_installed.py 2017 -w 10.0.17134.0
>
> Bug: 773476
> Change-Id: Ic819f3ae79d7e869227bf33fbb8d202e2f57039b
> Reviewed-on: https://chromium-review.googlesource.com/1054027
> Reviewed-by: Nico Weber <thakis@chromium.org>
> Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#559033}
TBR=thakis@chromium.org,dpranke@chromium.org,hubbe@chromium.org,brucedawson@chromium.org
Change-Id: Ib8e84084a9717dafa6616f132b4824d93cbf39bf
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 773476
Reviewed-on: https://chromium-review.googlesource.com/1063810
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#559471}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 7ad7e759dd35a114375a671f02669c9a0283bea1
This change switches the VS 2017 package to use VS 2017 Update 7.1 while
using the 10.0.17134.12 SDK. The new SDK is needed to support new HDR
features, and to stop forcing external developers to install an old
([Spring] Creators Update) SDK. This change will also bring in a new
linker and other build tools, but the version of clang-cl will be
unchanged.
Packaging was done on a Windows Server 2016 VM, cleanly created for this
purpose.
Compiler was packaged up by downloading VS 2017 Update 7.1, from
https://www.visualstudio.com/vs/, and then passing these parameters to
the installer:
--add Microsoft.VisualStudio.Workload.NativeDesktop
--add Microsoft.VisualStudio.Component.VC.ATLMFC --includeRecommended
--passive
Then Add or Remove Programs was used to modify the 10.0.17134.0 SDK to add
the Debuggers package.
Then the packaging script was run like this:
python depot_tools\win_toolchain\package_from_installed.py 2017 -w 10.0.17134.0
Bug: 773476
Change-Id: Ic819f3ae79d7e869227bf33fbb8d202e2f57039b
Reviewed-on: https://chromium-review.googlesource.com/1054027
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#559033}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 5a7f3c442684be5eeb244b904bbfc8e6edaf6fda
LLVM has been updated in the ChromeOS sysroot, so it should be safe to enable
thin archives now.
BUG=801925
Change-Id: I7dc2492937a26adc4f9af61abccbdb086e3a38cb
Reviewed-on: https://chromium-review.googlesource.com/1050980
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#557336}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 1ed851337f4781d2504bdcc03f11d1ffb5526a3a
This was changed by r554983, which really should have only changed the
android OS check, as Linux builds also need to support NaCl toolchains
where current_os != "linux".
Bug: 822034
Change-Id: I5ca924516158bdd6228b947f32db6b614d1caacd
Reviewed-on: https://chromium-review.googlesource.com/1038430
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Ken Rockot <rockot@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#555228}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: c77b371695be9335ffe86608871d9dc2fd537d8a
This is an unmodified reland of r554617 after fixing cases where
target_os=["chromeos"] was not set in some Chrome OS builders'
gclient configs.
Causes Chrome builds for Chrome OS to emit additional 32-bit and
64-bit copies of the mojo_core shared library built against the
Android toolchain, for use from within the ARC++ container.
In order to support building these library targets, this also
modifies DEPS to include a minimal set of required Android support
tools and libraries in chromeos checkouts.
Bug: 822034
Change-Id: I0e6ae87a1b9da80b82c40fd637a5be07dd7b8272
Reviewed-on: https://chromium-review.googlesource.com/1035619
Commit-Queue: Ken Rockot <rockot@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#554983}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 027d7fa1c191f60f754985b9c235597f8c9a2081
The original patchset has a minor flaw in building for UWP unrelated to the changes made in the original CL itself. $target_cpu is used in "host" toolset instead of $host_cpu and when building an arm target it causes issues as it can't build host tools.
Fixes an error introduced in crrev.com/c/923161
R=brucedawson@chromium.org, dpranke@chromium.org, phoglund@chromium.org
Bug: 812814
Change-Id: Ia6e7f1dc2b5494e212d67b99a119e023a1308c25
Reviewed-on: https://chromium-review.googlesource.com/1022493
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Commit-Queue: Patrik Höglund <phoglund@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#554707}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 86ac3fe7e3327a67ba131764738ed5cdb3685fff
This reverts commit 58eabf0b4f69f136629286538c31c10e9375c51c.
Reason for revert: Broke ChromeOS ASan builder
Original change's description:
> Build 32- and 64-bit Android mojo_core for Chrome OS distribution
>
> Causes Chrome builds for Chrome OS to emit additional 32-bit and
> 64-bit copies of the mojo_core shared library built against the
> Android toolchain, for use from within the ARC++ container.
>
> In order to support building these library targets, this also
> modifies DEPS to include a minimal set of required Android support
> tools and libraries in chromeos checkouts.
>
> Bug: 822034
> Change-Id: I219837de3076490cdea8315e6cc98c5432871ea0
> Reviewed-on: https://chromium-review.googlesource.com/1026203
> Commit-Queue: Ken Rockot <rockot@chromium.org>
> Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#554617}
TBR=rockot@chromium.org,dpranke@chromium.org
Change-Id: I2e2b0d3500aa948f15ec7cf0ff024f7a82fd719d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 822034
Reviewed-on: https://chromium-review.googlesource.com/1033369
Reviewed-by: Abhishek Arya <inferno@chromium.org>
Commit-Queue: Abhishek Arya <inferno@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#554632}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 9591f2badbd80682049c16a00df7df1625fce19e
Causes Chrome builds for Chrome OS to emit additional 32-bit and
64-bit copies of the mojo_core shared library built against the
Android toolchain, for use from within the ARC++ container.
In order to support building these library targets, this also
modifies DEPS to include a minimal set of required Android support
tools and libraries in chromeos checkouts.
Bug: 822034
Change-Id: I219837de3076490cdea8315e6cc98c5432871ea0
Reviewed-on: https://chromium-review.googlesource.com/1026203
Commit-Queue: Ken Rockot <rockot@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#554617}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 58eabf0b4f69f136629286538c31c10e9375c51c
This reverts commit 953fcf3fe08d99068f2a4b39081a2ab55dae178a.
Reason for revert: We want to set envvar directly.
Original change's description:
> Add disable_goma for args.gn on win
>
> Switching use_goma causes full rebuild due to command line update in build.ninja.
> I added disable_goma to set GOMA_DISABLED on environment.{x86,x64}.
>
> If we specify disable_goma=true, GOMA_DISABLED env is passed to gomacc.
> Then gomacc executes given argument instead of sending args to goma daemon.
>
> This will help toolchain maintainer to check difference of build behavior w/wo goma without rebuilding everything.
>
> Bug:
> Change-Id: Ie58958b5484d57be1c40fbbca363f1eef4b55c7e
> Reviewed-on: https://chromium-review.googlesource.com/768549
> Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
> Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#518134}
TBR=dpranke@chromium.org,brucedawson@chromium.org,tikuta@chromium.org
Change-Id: Ia2d510f4149b30cff3f8dc6c0b89e37190c39368
Reviewed-on: https://chromium-review.googlesource.com/1015860
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#551602}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: ee4c20c2074018c75d297647820d1d58f82fd7c9
This sets is_posix to false for the Fuchsia build as it will rely less
and less on the POSIX implementation. Follow-up CLs will clean up build
files from redundant checks and stop including _posix files by default.
Bug: 812974
Change-Id: I6dc625ba2d4919a775041b1516e051b471c50e97
Reviewed-on: https://chromium-review.googlesource.com/987377
Commit-Queue: Fabrice de Gans-Riberi <fdegans@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Ken Rockot <rockot@chromium.org>
Reviewed-by: Chrome Cunningham <chcunningham@chromium.org>
Reviewed-by: Sergey Ulanov <sergeyu@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#550292}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 9fba3affd0a3246f2ec851c5f83cc3588a379086
With the following gn args:
use_goma = true
is_debug = false
is_component_build = false
Reduces the size of the out directory from 2.4G to 1.8G and reduces
build time from 1m36s to 1m20s.
BUG=801925,829956
Change-Id: Ie426ae7b16385a166147bcb149694df7c93c2e14
Reviewed-on: https://chromium-review.googlesource.com/978648
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#548918}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 40a8d84a54ac47d3299194c5377aebd71714f1f0
This creates problems when running on a case sensitive file system.
When the path of a checkout contains uppercase characters, the
following command fails:
$ gn gen out/win64 --args='target_os="win" target_cpu="x64"'
ERROR at //build/config/win/BUILD.gn:338:27: Script returned non-zero exit code.
vcvars_toolchain_data = exec_script("../../toolchain/win/setup_toolchain.py",
.... src/build/toolchain/win/setup_toolchain.py", line 240, in main
assert vc_bin_dir
AssertionError
Bug: None
Change-Id: If4c792e9d04d56987a87a55e824d764a1c4e62ed
Reviewed-on: https://chromium-review.googlesource.com/985835
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Commit-Queue: Mirko Bonadei <mbonadei@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#547994}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 4e699af35744098fc7949942301c9baa1943c162
Improve bootstrap for Windows and allow bootstrap to work in specified
target directory. Additionally, some fixes made to project generation,
and for Linux.
R=dpranke@chromium.org
Change-Id: Ied7f99d3cb83559fbde597cb707b46fcb3e98dc4
Reviewed-on: https://chromium-review.googlesource.com/941214
Commit-Queue: Yngve Pettersen <yngve@vivaldi.com>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#547867}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 73b7854e6d4c7a186047809aacb9ce1478277c7a
This is required to support building Microsoft's WinUWP store
application version of WebRTC.
vs_toolchain.py
- needed to perform environment variable expansion for "Program
Files(x86)" to correctly identify Visual Studio installation location
config/BUILD.gn
- remove delayimp.lib, kernel32.lib and ole32.lib from store
applications (instead requires dloadhelper.lib/WindowsApp.lib
must be used)
BUILDCONFIG.gn
- Do not use clang when compiling Windows UWP targets;
- Added declare_args for is_target_winuwp rather and stripped multi
defined variations of the host_os/current_os == "winrt_10", "winrt_81",
"winrt_81_phone" that heavily polluted the platform / target selections
(as the current targeting methodology is incorrect anyway). The
host_os/current_os is always be "win" and only the target should be
Windows UWP / store applications based on the target_os == "winuwp"
rather than all the flavors of UWP.
- Added filter for _winuwp source files (separate from just windows)
- Added default configs for desktop vs store applications to correctly set
the defines according to the desktop vs store targets
config/win/BUILD.gn
- The Windows UWP versioning assumes to be Windows 10 / store
app now although a updated GN allows for targeting older Windows UWP
versions/SDKs/device families. This allows the definitions for the
various application support versioning and application families required
for UWP to be set.
- The linker calls vsvarsall.bat to be executed via
toolchain/win/setup_toolchain.py in order to correctly identify the
correct linker library path information for Windows store SDK targets.
The hard coded and assumed library paths are fixed in all cases to be
discovered from the tooling for forward future platform support in all
cases.
- Added ARM linkage definitions for the Windows ARM CPU required for
properly targeting all three CPUs (x86, x64, arm) for universal store
binaries.
- Added the proper family C++/C defines required to target the various
Windows store application types currently offered for Windows UWP store
applications.
toolchain/win/BUILD.gn
- The name to support the storage of the environment variables now is
passed into the setup script to allow for easier extension of the
CPUs and target combinations (arm, x64, x86 in the desktop vs store
variations)
- "desktop" vs "store" is now specified the setup for the
correct toolchain targeting
- Sets true/false for is_target_winuwp is dependent on the toolchain
activated (so configurations will be set correctly when the toolchain is
specified for host tool targets required for build tools vs finalized
application targets)
- Cleaned up the Windows RT section to properly support Windows UWP
toolchains
toolchain/win/setup_toolchain.py
- the setup was missing the arm CPU for universal binaries required for
the UWP platform
- The calling of vcvarsall.bat was missing the "store" option for store
applications and all the CPU offered
- Added returning of linker paths by searching the library environments
for well-known library files expected in each of the 3 library paths
required "lib", "um" and "atlmfc"
R=phoglund@google.com
Bug: 812814
Change-Id: If1a6b1b1bc3ed940fc8e2ce726ac016e2491e61d
Reviewed-on: https://chromium-review.googlesource.com/923161
Commit-Queue: Patrik Höglund <phoglund@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#545751}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: c5686578e8f519eeec50f574b284fbc12e6e15d8
This bug has been archived with a message instructing people to report bugs to
https://bugs.llvm.org/.
BUG=695243
Change-Id: I5c6655d52797d41229435788632887908f7cb2af
Reviewed-on: https://chromium-review.googlesource.com/973441
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Rob Percival <robpercival@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#544831}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 248c8d1ddfb6783f558b191115a33be8bc617564
"Mac Builder Goma Canary" builder is failing with "Argument list
too long". The length of command line exceeds 220K, so it's
actually long.
Though libtool on Mac does not support @rsp file, it supports
-filelist. So we can pass a file list via a file.
-filelist takes a file list separated by a new line, so we can
abuse rspfile for this purpose.
"solink", "solink_module", and "link" are doing the same thing,
so I believe this is acceptable.
Bug: 820900
Change-Id: I583d320ac96f959b1a7c3d878a882d17f63cb566
Reviewed-on: https://chromium-review.googlesource.com/964033
Commit-Queue: Shinya Kawanaka <shinyak@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#543965}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 0a289a6f991239e4472cf373b021529e0344c4c8
Avoid using "cmd /c" on non-Windows platforms. This fixes the Windows
cross build in a couple of cases.
Change-Id: I4da82e50abbc392dbd90afe34befacc9bce9a593
Reviewed-on: https://chromium-review.googlesource.com/920762
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Peter Collingbourne <pcc@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#537221}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 1f49f5de7b13240487312daab67135e35bce93bc
If developer installs goma to location different from $HOME/goma,
GOMA_DIR should be set as per official goma docs.
Change-Id: I35d952a837f6f734ef9d45e415d5a49596f88b58
Reviewed-on: https://chromium-review.googlesource.com/918681
Commit-Queue: Greg Kraynov <kraynov@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#536772}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: d00240d699a22545f09c04a4ee5085adbc300985
This changes the Clang version number from 6.0.0 to 7.0.0.
Bug: 803661
Change-Id: Ib717cadcb3873d6dc3e49267629f7ffc1acf1df7
Reviewed-on: https://chromium-review.googlesource.com/903927
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Hans Wennborg <hans@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#535693}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: ca5066b992b8a05e6a3df042f2c0e1766e13a565
Invoking cpu intensive python processes more than machine cores has some overhead on Mac(crbug.com/695864) and Win.
This change introduces pool mainly for python generator to restrict the number of running process when we specify large parallelism with goma.
I took 3 time build stats using target generate_bindings_modules_v8_interfaces and generate_bindings_core_v8_interfaces which have 1148 python tasks.
With this CL on z840 windows10
TotalSeconds : 18.2953436
TotalSeconds : 18.6283626
TotalSeconds : 19.2731436
Without this CL on Z840 windows10
TotalSeconds : 23.8277797
TotalSeconds : 23.6952018
TotalSeconds : 23.0853999
Linux looks to have good task scheduler.
With this CL on z840 linux
0m9.067s
0m8.771s
0m8.953s
Without this CL on Z840 linux
0m8.998s
0m9.022s
0m8.958s
Also this improves UI's responsiveness when we are building chrome on windows.
Stats of clean chrome build in each major OS is like below.
5 time clean build of chrome on Z840 windows 10 with -j1000 and warm goma backend cache is like below.
With this CL
333.3425057
317.4724857
305.0217898
317.8907203
305.1031952
Avg: 315.76613934
Without this CL
369.9731363
331.296758
329.0041556
329.1472297
333.3883952
Avg: 338.56193496
5 time clean build of chrome on Z840 linux with -j1000 and warm goma backend cache is like below.
With this CL
90.42
87.91
90.45
90.50
89.02
avg: 89.66
Without this CL
89.52
86.34
86.08
85.67
85.89
avg: 86.7
3 time clean build of chrome on 24 thread Mac Pro with -j500 and warm goma backend cache is like below.
With this CL
638.28
627.28
624.69
avg: 630.083
Without this CL
667.52
663.83
655.95
avg: 662.433
Bug: 695864
Change-Id: I6838c0f71b8d8030e6eab58b2990810aaa997dfa
Reviewed-on: https://chromium-review.googlesource.com/882581
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#535589}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 2c098797567226115653c2567dbcfc72ee5af5ae
This is mainly for faster compile step on win7_chromium_rel_ng.
I checked amount of peak memory consumption for some large targets via task manager with args.gn of win7_chromium_rel_ng.
unit_tests.exe 1.9~2.0 GB
browser_tests.exe 1.9~2.0 GB
interactive_ui_tests.exe 1.7~1.8 GB
chrome.exe 0.9~1.0 GB
So 3GB will be sufficient.
Tested on CQ with https://chromium-review.googlesource.com/c/chromium/src/+/897235/13
Bug: 804251
Change-Id: I4b17287fd8757f007c81b4a484a1b0371435dbe3
Reviewed-on: https://chromium-review.googlesource.com/897235
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Takuto Ikuta <tikuta@google.com>
Cr-Original-Commit-Position: refs/heads/master@{#534327}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 799c810b24e6471bb192e3c6981071cb2ffa1d49
The packaging step now uses the binaries which were stripped via
"eu-strip". The unstripped binaries are included in the build
output as runtime dependencies, to support symbolization.
Bug: 792521,788851
Change-Id: I73351d7e68c81487591e85c9b598effec9ff45a6
Reviewed-on: https://chromium-review.googlesource.com/891628
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Wez <wez@chromium.org>
Commit-Queue: Kevin Marshall <kmarshall@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#533445}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 3d0153fb52415ac79ffbbd3da589a8378a7ba59c
On about 3-4% of Chrome builds on my workstation one of the executables
generated and then used during the build will crash. The binary on disk
is always fine but the loader sometimes maps in pages of zeroes where it
should be mapping in pages from the just-generated binary. Having a page
of zeroes where you are expecting useful instructions tends to lead to
crashes.
This appears to be a bug in the OS disk cache. My suspicion is that this
kernel bug only happens on multi-socket systems, but this is
speculation.
This bug happens regardless of which compiler or linker is used, and
appears to happen on multiple Windows versions. The best reproes have
been on Windows 10 Creators Update, or at least that is where I have
done most of my testing.
Extensive testing - hundreds of overnight builds - has shown that the
problem goes away if FlushFileBuffers is called on the output file
after linking is finished. Eventually this fix/hack will be coded into
lld-link.exe, but for now it is put in tool_wrapper.py to fix the bug
for both link.exe and lld-link.exe.
Earlier versions of this fix only applied it to files with .exe
extensions. However the bug is believed to have happened with DLLs, and
may also affect .lib files created by the linkers, so now it is done
always. The belief is that the performance impact will be negligible.
Importing of win32file required some trickiness because in the context
of ninja builds of Chrome the depot_tools python.bat file is apparently
not called. This means that the python directory is not added to the
system path. The python runtime correctly finds win32file.pyd and calls
LoadLibrary on it but the OS then finds its dependencies in another
version of python installed on the system and the DLL load fails if
those are 64-bit instead of 32-bit.
Bug: 644525
Change-Id: I71d63b47050385e2e5ba46ced9c8018220370ba7
Reviewed-on: https://chromium-review.googlesource.com/876683
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Zachary Turner <zturner@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#533137}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 052a09014b2018e2a1e3b7f046ea9ad3355b831e
This reverts commit 848e109661ef338dedcd8d2d59f281308b9ec1c9.
Reason for revert: chromeos trybots are all failing compiles.
Bug: 807145
NOTRY=true
Original change's description:
> Allow more concurrent link for linux_chromium_rel_ng builder
>
> I took peak memory usage stats for top3 largest binary link using the same args.gn with linux_chromium_rel_ng.
> 229MB chrome: 2.22 GB peak memory
> 260MB browser_tests: 2.56 GB peak memory
> 258MB unit_tests: 2.57 GB peak memory
>
> So 3GB is sufficient.
>
> This will help to speed up build like below.
> https://ci.chromium.org/buildbot/tryserver.chromium.linux/linux_chromium_rel_ng/634117
> ninja trace: https://chromium-build-stats.appspot.com/ninja_log/2018/01/29/slave645-c4/ninja_log.slave645-c4.chrome-bot.20180129-023145.30339.gz/trace.html
> Some newlib_pnacl related binary prevent mksnapshot to be linked due to small link pool and many targets indirectly depends on mksnapshot.
>
>
> Change-Id: I7c58aec10949c350bbce0a97704048caf44f5b96
> Reviewed-on: https://chromium-review.googlesource.com/891043
> Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> Commit-Queue: Takuto Ikuta <tikuta@google.com>
> Cr-Commit-Position: refs/heads/master@{#532662}
TBR=thakis@chromium.org,dpranke@chromium.org,tikuta@google.com
Change-Id: I3d6a0cdc7df943731755f926ab0a5d3a0670bb5f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/891844
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#532744}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 1c99068c887584d085d0ea13370d3f6dab67f8b5
Removes myself from all owners files except tools/gn.
Replace myself with dpranke for owners of BUILDCONFIG.gn
TBR=jam@chromium.org
Change-Id: I015c6724ba04c07a9954107e1f5319ff3ef480ce
Reviewed-on: https://chromium-review.googlesource.com/891669
Reviewed-by: Brett Wilson <brettw@chromium.org>
Commit-Queue: Brett Wilson <brettw@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#532534}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: c466dc805f8aa911524deee91e49e534f69ada03
c:\src is more often whitelisted for virus scanners, so putting goma there
can make your build faster and is now officially recommended.
If you have goma in c:\goma, move it to c:\src\goma.
See also internal thread titled
"Are you using goma on Windows? Move goma install to C:\src\goma\goma-win64"
Bug: none
Change-Id: Idc608cad64b388e6030afccb0dee4c647000be90
Reviewed-on: https://chromium-review.googlesource.com/883661
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Hans Wennborg <hans@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#531530}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 6e48cec330a089c2540a99a0035dc31a8c2607cc
Creating and deleting rsp files is time consuming part when building on windows with warmed goma backend cache.
To reduce such bottleneck, we can use all compiler flags directory in command line instead of using rsp file.
This CL keeps using rsp file for linking because linking flags can be longer than compiles and the number of linking is relatively small compared to compile.
I took 3 time build stats for 'chrome' on 48 thread Z840 windows 10 with following args.gn and -j 500.
```
goma_dir = "C:\\src\\goma_client\\client\\out\\Release"
is_component_build = true
is_debug = false
strip_absolute_paths_from_debug_symbols = true
symbol_level = 0
target_cpu = "x86"
use_goma = true
is_clang = false
enable_nacl = false
use_lld = true
```
* With this CL
TotalSeconds: 279.9604737
TotalSeconds: 279.4099064
TotalSeconds: 273.8253059
Avg: 277.731895333333
* Without this CL
TotalSeconds: 325.0155664
TotalSeconds: 319.4094433
TotalSeconds: 299.9709
Avg: 314.798636566667
Bug: 796021
Change-Id: Ice959c196b6879b39962a3b628cdcf531884ec36
Reviewed-on: https://chromium-review.googlesource.com/832593
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Takuto Ikuta <tikuta@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#529137}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: d2164444bcfdf6e4e5eadc55bcfb77fd74f9dba8
-fsanitize=fuzzer and -fsanitize=fuzzer-no-link are two compilation
flags that enable coverage instrumentation needed for libFuzzer.
The instrumentation has more stuff under the hood compared to
-fsanitize=trace-pc-guard. Also, it can be changing over time
without a need to update GN flags again and again (e.g. move from
edge to trace-pc-guard or something like that).
Bug: 764514
Change-Id: I53bf5a3355335f4f627e9024b7ed7fe601c9ecfd
> Revert "Migrate to -fsanitize=fuzzer-no-link when use_fuzzing_engine=true."
>
> This reverts commit c1406d52464e16da16aae9cb189c4f28e6412358.
>
> Reason for revert: The builds are failing on linking of some fuzzers: https://logs.chromium.org/v/?s=chromium%2Fbb%2Fchromium.fyi%2FLibfuzzer_Upload_Linux_ASan%2F7088%2F%2B%2Frecipes%2Fsteps%2Fcompile%2F0%2Fstdout
>
> Original change's description:
> > Migrate to -fsanitize=fuzzer-no-link when use_fuzzing_engine=true.
> >
> > -fsanitize=fuzzer and -fsanitize=fuzzer-no-link are two compilation
> > flags that enable coverage instrumentation needed for libFuzzer.
> >
> > The instrumentation has more stuff under the hood compared to
> > -fsanitize=trace-pc-guard. Also, it can be changing over time
> > without a need to update GN flags again and again (e.g. move from
> > edge to trace-pc-guard or something like that).
> >
> > Bug: 764514
> > Change-Id: I48ef328dee49a9620a1b44bd5cd920f116e1bc1b
> > Reviewed-on: https://chromium-review.googlesource.com/802395
> > Commit-Queue: Max Moroz <mmoroz@chromium.org>
> > Reviewed-by: Oliver Chang <ochang@chromium.org>
> > Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#522505}
Change-Id: I53bf5a3355335f4f627e9024b7ed7fe601c9ecfd
Reviewed-on: https://chromium-review.googlesource.com/846100
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Max Moroz <mmoroz@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#526592}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: ddd48e3299a1adf1e12f4d1fe680fd47eac8700d
Adding -Wl,--start-group, -Wl,--end-group so that ld.bfd
can resolve library dependencies in case of Android
component build for mipsel.
Bug: 794486
Change-Id: I9ce1867b614aea51382637bc59aa7c7b8c2adbde
Reviewed-on: https://chromium-review.googlesource.com/823905
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#525039}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 71279763dbdd0d8d3a3cb1fb038587ab752ace47
Stripping binaries entirely before shipping them to swarming clients to
be run prevents us from symbolizing stack traces. Since the effect on
binary & bootfs size is not all that great for Release, nor for Debug
component builds, disable stripping entirely for now.
Bug: 792521
Change-Id: Ie9031e26dcd9f77ee17e5bb3648f0ad13839f61f
Reviewed-on: https://chromium-review.googlesource.com/818505
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Wez <wez@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#523222}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: e1e1c872d3e7c9af677673b493e209b3cb845e8c
Takuto Ikuta
Nico Weber
Bruce Dawson
Tom Anderson
Ken Rockot
Robin Raymond
Abhishek Arya
Fabrice de Gans-Riberi
Mirko Bonadei
Yngve N. Pettersen
tzik
Rob Percival
Shinya Kawanaka
Takuto Ikuta
Sebastien Marchand
Peter Collingbourne
Greg Kraynov
Hans Wennborg
agrieve
Scott Graham
Kevin Marshall
John Abd-El-Malek
Brett Wilson
Roger Tawa
Max Moroz
Gordana Cmiljanovic
Wez