Like https://chromium-review.googlesource.com/c/chromium/src/+/1711087 but
for generate_breakpad_symbols.py
Also make sure hermetic otool is available at test execution time when
it's available at build time.
Bug: 984746,998873
Change-Id: I9646e48d3dae3f6f1076ed9e3ddbd91eb1e1cfd1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1803805
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Auto-Submit: Nico Weber <thakis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#696596}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 51a61da45d1648328012f3d25876b9edaf2550c1
dSYMs are listed as outputs on the toolchain’s link rule,
so they do not need to be listed explicitly by targets.
Bug: 330301
Change-Id: I7eca7b8a6b1bcddffead9c2f55d6d16b8c975254
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1801324
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#696076}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 9e68847f01883c73aa1d3b884305f1e6e13ae252
This requires a sufficiently new version of ld64. I confirmed that the one that
comes bundled with Xcode 10.12.1 is new enough. There's no harm in setting this
for older versions of ld64.
This is currently gated behind the gn arg mac_deterministic_build because lldb
has a bug that causes it to fail to load object files when the binary is built
deterministically.
Bug: 330262
Change-Id: I9802420a46f487888f4768c01168dae1b8d88359
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1711105
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Auto-Submit: Erik Chen <erikchen@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#687360}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 7dc7c87cff652ab9a63f83029682c488e3ba515d
The argument is now unused. This CL should not have a behavior change.
Bug: 965663
Change-Id: Ibc69066c8a8883fa7e1c28ba5f3b76a395e60ac9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1652718
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#668372}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 6cd46be7b83ad5d8592c9709a2e9df6ae60202c6
When we use the hermetic toolchain, all binaries are specified by path. Since we
no longer use xcrun to find the binaries, we also no longer need DEVELOPER_DIR.
Bug: 971452
Change-Id: I46499bef18afc19e51aae943047fd33beecac75c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1650281
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#667280}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: b5f646147dee024274d30f24b5ce939c32fa2887
This allows the macOS toolchain to avoid using xcrun to find the path for strip.
Bug: 971452
Change-Id: I7d7b87462ee33201b57a75bfa58e5fbf8ddaee5f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1649187
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#667215}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 2eaf8f5a560c5b86a74b97c9e5623b72c106c433
This CL is a refactor with no intended behavior change.
Bug: 965663
Change-Id: I07a61658d730c0982e52f7e496d05cb274c9ef2d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1648695
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#667184}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 7479370d8d92077c27d77434ace959a331ce1182
Linking on macOS is invoked via clang++. If clang++ cannot find ld on the
default search path, clang++ will invoke xcrun to search for ld. This CL
explicitly passes the path to ld if we're using hermetic xcode. This way clang++
will not invoke xcrun.
Bug: 971452
Change-Id: I5bcaa577d9ccc6d3ceca6e2524482e299b371e92
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1649179
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#667154}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: ea5d6db4f364752de2a5d71e44ced11784475a55
Both binaries show up in the default macOS search path, but as minimal wrappers
around xcrun. By specifying the paths explicitly, we avoid calls to xcrun.
Bug: 971452
Change-Id: Ia852f4b9991fd548f3c83bc04fdda7389e44a72a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1649223
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#667153}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: bcdbc4c814be4fc16af355b88d4f6788e78fe7f7
This reverts commit 6f979049822acf3e4cde9b34f5dcfeb8e94745e5.
Reason for revert: This doesn't cause compile failure.
I have to revert
https://chromium-review.googlesource.com/c/chromium/src/+/1649054
Original change's description:
> Revert "Use explicit path for libtool rather than implicit invocation of xcrun."
>
> This reverts commit 1f49775ab209ba5668029cdffe63f40ce5e98668.
>
> Reason for revert: causes compile failure on Mac ASan 64 Builder
> https://ci.chromium.org/p/chromium/builders/ci/Mac%20ASan%2064%20Builder/84739
> https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket.appspot.com/8911354223898031376/+/steps/compile/0/stdout
>
>
> Original change's description:
> > Use explicit path for libtool rather than implicit invocation of xcrun.
> >
> > libtool is part of the default path at /usr/bin/libtool. That binary is just a
> > shim that calls out to xcrun to find the actual libtool. If we're using hermetic
> > xcode, then we can explicitly specify the path to avoid invoking xcrun.
> >
> > Bug: 971452
> > Change-Id: If9344a244160ccc43895cf913d48f9c9a44ac5d9
> > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1648836
> > Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> > Commit-Queue: Erik Chen <erikchen@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#666906}
>
> TBR=dpranke@chromium.org,erikchen@chromium.org
>
> Change-Id: I0cdc4acdff512213116ecd872230b6d7b634b865
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: 971452
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1647598
> Reviewed-by: Takashi Sakamoto <tasak@google.com>
> Commit-Queue: Takashi Sakamoto <tasak@google.com>
> Cr-Commit-Position: refs/heads/master@{#666983}
TBR=dpranke@chromium.org,tasak@google.com,erikchen@chromium.org
Change-Id: I1180b957926016864fcb83f351985ce6ec4fb8bb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 971452
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1647600
Reviewed-by: Takashi Sakamoto <tasak@google.com>
Commit-Queue: Takashi Sakamoto <tasak@google.com>
Cr-Original-Commit-Position: refs/heads/master@{#666985}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 20fb0ca2321693ac194b9efd7c83d8a4b856fdb4
This allows the macOS toolchain to avoid using xcrun to find the path for strip
and dsymutil.
Bug: 971452
Change-Id: Ib3d8865c44e1d95ed2fe22b6393d7e1549f9e621
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1649054
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#666915}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 9cc11952e44ef12a6f4b16ff4e310f838bd0319f
libtool is part of the default path at /usr/bin/libtool. That binary is just a
shim that calls out to xcrun to find the actual libtool. If we're using hermetic
xcode, then we can explicitly specify the path to avoid invoking xcrun.
Bug: 971452
Change-Id: If9344a244160ccc43895cf913d48f9c9a44ac5d9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1648836
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#666906}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 1f49775ab209ba5668029cdffe63f40ce5e98668
xcassets are only used on iOS, not macOS. We want to minimize the number of
Xcode-based tools used by the macOS toolchain, so we intentionally disallow
future uses of xcassets on macOS.
Change-Id: Id559f84633be6c935211561b976a7991810d94ad
Bug: 965663
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1643406
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#666695}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 6c478646f25b58fe24c885b76f3f3e5c0a0fcd51
This reverts commit 28c84c16d28cba67c4ec61997632f71583453d22.
Reason for revert: https://crbug.com/969587
Original change's description:
> [Mac] Preserve symbolic links in the copy_bundle_data tool
>
> This is a reland of 6a008993a2e5, which was reverted in 235d842aa70a.
> (Thus, this is a revert of that revert.)
>
> Since the last attempt, the structure of the keystone_registration
> bundle_data rule in third_party/googlemac (via src-internal DEPS) has
> changed to avoid the dangling symbolic link problem previously
> encountered.
>
> The description from 6a008993a2e5:
>
> The copy_bundle_data tool is implemented in terms of pax for directories
> and ln hard links for files. The pax command does preserve symbolic
> links within the tree that is being copied. But with the way that pax is
> invoked by the tool, cd-ing into the source, if the source is itself
> a symbolic link to a directory, the tree will be logically copied rather
> than just as a symbolic link.
>
> A similar issue exists with the non-directory symbolic link source case,
> where a hard link will be produced instead of a symbolic link.
>
> Fix both of these cases by specifically testing if the source is a
> symbolic link and then re-creating it if so.
>
> Bug: 955936
> Change-Id: Ia13ddf743603e98337c3523e9101e7627e1c31d0
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1637673
> Reviewed-by: Nico Weber <thakis@chromium.org>
> Commit-Queue: Mark Mentovai <mark@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#665203}
TBR=thakis@chromium.org,mark@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: 955936
Change-Id: I4de6596c29598961ac15fbd24acc54b1f763735a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1639152
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#665543}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 13865f386b4286efad2d98e0c7118ed614ce92df
This is a reland of 6a008993a2e5, which was reverted in 235d842aa70a.
(Thus, this is a revert of that revert.)
Since the last attempt, the structure of the keystone_registration
bundle_data rule in third_party/googlemac (via src-internal DEPS) has
changed to avoid the dangling symbolic link problem previously
encountered.
The description from 6a008993a2e5:
The copy_bundle_data tool is implemented in terms of pax for directories
and ln hard links for files. The pax command does preserve symbolic
links within the tree that is being copied. But with the way that pax is
invoked by the tool, cd-ing into the source, if the source is itself
a symbolic link to a directory, the tree will be logically copied rather
than just as a symbolic link.
A similar issue exists with the non-directory symbolic link source case,
where a hard link will be produced instead of a symbolic link.
Fix both of these cases by specifically testing if the source is a
symbolic link and then re-creating it if so.
Bug: 955936
Change-Id: Ia13ddf743603e98337c3523e9101e7627e1c31d0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1637673
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#665203}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 28c84c16d28cba67c4ec61997632f71583453d22
This reverts commit 6a008993a2e54af93edd956a53c786668bc0e253.
Reason for revert: https://crbug.com/966766, more information at https://crbug.com/955936 beginning at comment 13
Original change's description:
> [Mac] Preserve symbolic link in the copy_bundle_data tool.
>
> The copy_bundle_data tool is implemented in terms of pax for directories
> and ln hard links for files. The pax command does preserve symbolic
> links within the tree that is being copied. But with the way that pax is
> invoked by the tool, cd-ing into the source, if the source is itself
> a symbolic link to a directory, the tree will be logically copied rather
> than just as a symbolic link.
>
> A similar issue exists with the non-directory symbolic link source case,
> where a hard link will be produced instead of a symbolic link.
>
> Fix both of these cases by specifically testing if the source is a
> symbolic link and then re-creating it if so.
>
> Bug: 955936
> Change-Id: I69cf96878e59b0b7b121ae46cba5bc1e81f261ae
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1626269
> Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
> Reviewed-by: Mark Mentovai <mark@chromium.org>
> Commit-Queue: Robert Sesek <rsesek@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#662575}
TBR=sdefresne@chromium.org,rsesek@chromium.org,mark@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: 955936
Change-Id: Ia1489278b62d0cdb33ed8980bbd6a6bcab0bb199
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1628045
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#663076}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 235d842aa70a59c872d89e16b4a65606db5fb000
The copy_bundle_data tool is implemented in terms of pax for directories
and ln hard links for files. The pax command does preserve symbolic
links within the tree that is being copied. But with the way that pax is
invoked by the tool, cd-ing into the source, if the source is itself
a symbolic link to a directory, the tree will be logically copied rather
than just as a symbolic link.
A similar issue exists with the non-directory symbolic link source case,
where a hard link will be produced instead of a symbolic link.
Fix both of these cases by specifically testing if the source is a
symbolic link and then re-creating it if so.
Bug: 955936
Change-Id: I69cf96878e59b0b7b121ae46cba5bc1e81f261ae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1626269
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#662575}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 6a008993a2e54af93edd956a53c786668bc0e253
The clang we ship no longer includes the static analyzer, so this flag
hasn't been working for a while. Remove it, and mb stuff for an FYI bot
that uses it.
The plan is to run the static analyzer through clang-tidy instead.
While here, also remove the 'win analyze' bot src bits, since that
bot depends on MSVC which we haven't supported in a while either,
and the little bit of GN code kept alive by it.
Bug: 925145,687243
Change-Id: I042d3cc9f512a024a6eae6a8e7d43aa2f9a74fea
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1538987
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Hans Wennborg <hans@chromium.org>
Auto-Submit: Nico Weber <thakis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#644866}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: db1eca94f6af3ebca12da507180ed20afe038b5d
The Xcode 9.3 dsymutil dies with "IO Error" when handling objects larger than
2**32 bytes; the upstream llvm one seems not to have this problem.
Bug: 780980
Change-Id: I6846383329bd28a65516c0ef3ad177e1a78d08f3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1500198
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Elly Fong-Jones <ellyjones@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#637756}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 99453a4326a2d09990877c4516a343028bf89f29
Sometimes we expect to build mac target without v8, but there is a
warning that v8_current_cpu is set as a build argument, but not
appeared in declare_args(). If the declaration file v8_target_cpu.gni
is not imported, we should not override it.
Change-Id: I04ef533a565fb9272aa1117ccea1bdee022f5c9a
Reviewed-on: https://chromium-review.googlesource.com/c/1369645
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#615530}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: a40281ad05cfadc7af229ed5657139b67c2beaed
Compiles shouldn't shell out to non-clang processes, and we know that
clang doesn't read DEVELOPER_DIR, so this shouldn't be needed.
Bug: 780980
Change-Id: I811786f567c517aee9a82867336da7b2adb3bf44
Reviewed-on: https://chromium-review.googlesource.com/c/1358698
Reviewed-by: Erik Chen <erikchen@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#613129}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: c70ff02e893652d6b3e2f3e91bcfd47cf0320ebf
This CL hooks the Clang code coverage wrapper into the build
toolchains, and specifically, a new build flag:
coverage_instrumentation_input_file is added to allow turning on/off
the wrapper and pass the list-files-to-instrument around.
Bug: 898695
Change-Id: I405ccbfc1796afa44534794d711f2953fac78f6d
Reviewed-on: https://chromium-review.googlesource.com/c/1309999
Commit-Queue: Yuke Liao <liaoyuke@chromium.org>
Reviewed-by: Takuto Ikuta <tikuta@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#604858}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 9619c7100bab3b50c280efd021f92722bd1ab48e
"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
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
* Removed the no-goma assertion since the bug has already been resolved.
* Changed the CC and CXX command to reflect the changes in the analyzer
wrapper script. (crrev.com/2667853004 and crrev.com/2748793004)
Bug: 791239
Change-Id: I0c7470213eb769e19f4db64fbb0421ee99a9a06e
Reviewed-on: https://chromium-review.googlesource.com/804607
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Commit-Queue: Yuwei Huang <yuweih@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#521818}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 02378e677739f2bedc13fd375ae73973b247c351
Filter the libtool warning about having multiple files with the
same base name in a static library archive. This only become an
issue if trying to extract files from an archive, not for link.
Bug: none
Change-Id: I4f73e131daa6fec62c8955dc6424ab3dfbf42338
Reviewed-on: https://chromium-review.googlesource.com/735132
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Sylvain Defresne <sdefresne@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#511604}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 28461051a72e690219c816699061aada6d7f1a4b
Change ios_app_bundle template to merge the generated Info.plist
with the partial .plist created by the asset catalog compiler to
support compiling application icon to Assets.car as is required
for application built with iOS 11.0 SDK.
Quote args of compile_xcasset.py in build/toolchain/mac/BUILD.gn
as some of them may be empty or contain shell special characters
(mostly spaces).
Bug: 764286
Change-Id: I453f3cbb34c82483bace9900c49e0f3b351b2635
Reviewed-on: https://chromium-review.googlesource.com/671050
Commit-Queue: Sylvain Defresne <sdefresne@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#503129}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: d73f3454a10aa2d20f50f1b145148380649e7849
The asset catalog compiler (actool) can generate a partial Info.plist
file that needs to be merged with the application Info.plist at build
time (this is needed to support application icon in Assets.car).
Add a --partial-info-plist flag to compile_xcassets.py that can be
used to control the path of the generated partial Info.plist. Also
inspect the list of asset catalogs to be compiled and pass correct
flags to enable their proper treatment by actool (.appiconset and
.launchimage are the only two supported currently).
If --partial-info-plist is not passed or empty, and the compiler
need this flag (i.e. if any special asset catalog is compiled), then
the script create a temporary file and pass it to the compiler.
Bug: 764286
Change-Id: I3f51e5b6ac65919275a3fafb3408d02686105e21
Reviewed-on: https://chromium-review.googlesource.com/668976
Reviewed-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Sylvain Defresne <sdefresne@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#503110}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 2d534feab40dd363424f5437ec4ba3579e172d55
The use_sanitizer_coverage arg is currently not supported by the
Chromium mac_clang_x64 toolchain. This CL removes the flag if
the toolchain is the secondary one and throws an assertion error
if the toolchain is the primary one. For more info see the
associated bugs. This is a follow up of CL 596748.
BUG=751212,753445
Change-Id: Ie2f2efcd15ba7bc9f99dafb3dd4a9c2a8535fdf1
Reviewed-on: https://chromium-review.googlesource.com/606724
Commit-Queue: Brett Wilson <brettw@chromium.org>
Reviewed-by: Brett Wilson <brettw@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#494085}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 2484887f6de2a7877d98f04ec9effad7312ca0c3
During compilation of assets catalogs, actool has the option of
recompressing the images (likely with pngcrush as used by older
version of Xcode). Add an option to wrapper script to control
whether this is enabled and disable it on iOS (as images have
already been optimised with imageoptim).
Bug: 738359
Change-Id: I8a2b855798bf5f2d221fe9dc1098f8649f77e5a4
Reviewed-on: https://chromium-review.googlesource.com/561777
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Sylvain Defresne <sdefresne@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#485208}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 7c708332548f834d469be0af9659ceecb3ab3fa9
Change compile_xcassets.py to keep all output in known sections
(except com.apple.actool.compilation-results) as some errors do
not follow the pattern that was used, discarding the compilation
error message.
Bug: 739163
Change-Id: Ide40508913e5d32111ad9ba2225745d67465023b
Reviewed-on: https://chromium-review.googlesource.com/563298
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Sylvain Defresne <sdefresne@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#485164}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: c8ddaa9787cdff766f819c402d2dcd6de796fa90
The script build/toolchain/mac/compile_xcassets.py tries to turn
actool warnings into errors and to discard unrelevant messages
but was too strict causing compilation failures when actool was
just printing informational messages.
Change the script to be less strict and only keep the warnings or
error matching the '.*\.xcassets:.* (error|warning): .*' pattern.
Add unit test that the new function to filter actool output works
as intended.
Bug: 739163,736068
Change-Id: I7a7e2c0765159e50809516c067703b6d59d91a8c
Reviewed-on: https://chromium-review.googlesource.com/561008
Commit-Queue: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#484728}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: b5820db5ef26d58bcdfe1ce6dcfb77130a8f879a
Xcode 9 claims to be about migrating running simulator services, which
annoyingly actool depends on. Ignore messages that contain:
'Attempting to remove the stale service in order to add'
BUG=
Review-Url: https://codereview.chromium.org/2953503005
Cr-Original-Commit-Position: refs/heads/master@{#482328}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 25b3576ea176115e5f1aeadea9aabacbc1812c8f
Xcode 9's beta introduced a CoreUI(DEBUG) message followed by a detail message
that can be ignored. Presumably this will be removed once Xcode 9 GMs.
BUG=730054
Review-Url: https://codereview.chromium.org/2928623002
Cr-Original-Commit-Position: refs/heads/master@{#477535}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 44098da69108f7a5525edbfb307cf73c9902de66
Currently, linking with goma causes goma 'local fallback', and goma
allows at most 1 link in parallel (without special flag).
In 520f95147c821e13003362194a5de003a9f5c8f9, linking with goma is
enabled (maybe accidentally). It's better not to use goma for
linking now.
Review-Url: https://codereview.chromium.org/2667383002
Cr-Original-Commit-Position: refs/heads/master@{#447858}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: c398506e3abc0799330e39144194d70c00e4032e
If "use_clang_static_analyzer" is enabled in args.gn, Clang builds will redirect compilation to use Clang's ccc-analyzer and cxx-analyzer for static analysis.
Review-Url: https://codereview.chromium.org/2617283002
Cr-Original-Commit-Position: refs/heads/master@{#445854}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 520f95147c821e13003362194a5de003a9f5c8f9
Stop going through goma (or other compiler wrapper) for the "link"
tool when building for macOS/iOS (to follow gcc_compiler.gni).
BUG=None
Review-Url: https://codereview.chromium.org/2613503002
Cr-Original-Commit-Position: refs/heads/master@{#442245}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 5adef79d6f465dddc30e88db148c5b69c7059448
iOS builds can set use_xcode_clang = true and use_system_xcode = false when
chromium clang is broken. This requires prepending DEVELOPER_DIR to clang/clang++, etc
BUG=669094
Review-Url: https://codereview.chromium.org/2578273002
Cr-Original-Commit-Position: refs/heads/master@{#439028}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: c360dbf9da64cbf1c6b2d63e87aab8eda61dd424
Nico Weber
Robert Sesek
Erik Chen
Takashi Sakamoto
Mark Mentovai
Raul Tambre
Elly Fong-Jones
Li Hao
Yuke Liao
Shinya Kawanaka
Takuto Ikuta
Yuwei Huang
stkhapugin@chromium.org
Sylvain Defresne
kapishnikov
Julien Brianceau
justincohen
kmarshall
jochen