I'm aware of two uses for cc_wrapper:
- Goma support for linking is experimental, and normally just falls
back to the local compiler.
- ccache site says it always falls back to the real compiler for
linking. https://ccache.dev/
The msvc toolchain already does not use cc_wrapper for linking; this
change removes it for gcc_like_toolchain. This matches Chromium, e.g.
2cde7f21ab/build/toolchain/gcc_toolchain.gni (221)
Change-Id: I7199c23343233a2435e4d28e7269f67efac36d72
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/234316
Commit-Queue: Mike Klein <mtklein@google.com>
Auto-Submit: Ben Wagner aka dogben <benjaminwagner@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
The current use of MMD appears to ignore all includes which are resolved
from pointy bracket includes or system paths. This can lead to very
interesting incomplete rebuilds (or no rebuild at all) when updating
third_party headers or when the system headers are updated. The use of
MD makes the build depend on all the headers transitively included no
matter how they were included. This greatly increases the dependencies,
but only so much as to make them correct (barring the ever difficult
issue of a file being created with the same name earlier in the search
path).
Change-Id: I852e617f23b4ff0c5b4eb3068455428c9568e078
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/232762
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
If you just use the right compiler driver wrapper, recent NDKs automate
lots of the stuff we used to have to do ourselves.
Simplifying further, bump baseline ndk_api from 16 (Jellybean) on 32-bit
machines and 21 (Lollipop) on 64-bit to 21 across the board. This makes
using libc++ a lot easier, as it hooks into a bunch of APIs that were
added in 18 and 21. There's probably some way to work around this, but
the easiest thing is to just roll up.
Tested building {x86,arm}x{32,64} from a Linux host,
and running { arm}x{32,64}.
Kind of flailing around in later CLs trying to get linking not to hang
on Windows. I figure it's got something to do with lld?
Cq-Include-Trybots: skia.primary:Build-Win-Clang-arm64-Release-Android
Change-Id: I340b06fb9d372281146679d932417aaba3196045
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/225506
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
* Enable data bundling for all test apps unless specifically disabled.
* Add support to bundle symbols so that the stack trace in Instruments
is correct.
Bug: skia:7525
Change-Id: I5eef9fa21ecee8f790b0736f5e23c9d678e47bef
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/205001
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Stephan Altmueller <stephana@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
The PATH change we make is the only thing that needs Windows style
paths (and won't be fixed by GN). So, undo the other backslashes,
and fix a minor error in the placement of the quote.
Bug: skia:8569
Change-Id: I4feecaac96a4cf4d221a93e852a63f597e25e892
Reviewed-on: https://skia-review.googlesource.com/c/175825
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Might open up some neat options like LTO builds.
If nothing it's nice to use each whole toolchain consistently.
Move around some bonus quotes a bit.
LLD doesn't understand /DEBUG:FASTLINK.
Change-Id: I27e3c97acea6980c5bd006394aebb1e103007edd
Reviewed-on: https://skia-review.googlesource.com/c/175981
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Compile using clang-cl rather than clang-cl.exe
Change-Id: Ibc0350c6d2a38dd3dbf4efdefa85a39ce418cb0c
Reviewed-on: https://skia-review.googlesource.com/c/175830
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
The ARM64 MSVC toolchain only includes some of the executables. Other
functionality is in DLLs that are located in the host (x64) toolchain
directory. Hopefully MS fixes this at some point.
Bug: skia:8569
Change-Id: I1a96c63c9bdcf656eb2d84b81636d54304766c20
Reviewed-on: https://skia-review.googlesource.com/c/175821
Commit-Queue: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
These flags let symbols cross-link from anything in the group.
This becomes useful if we try to make more parts of Skia
components, letting binaries link .a static libraries that
depend on each other without worrying about the order they're
specified on the link line / in the .rsp file.
Few of our bots should be affected by this, as lld doesn't
really need this workaround.
Change-Id: I75f4cc069a2c82c7898d510a6b8b5cf1b8bdbe50
Reviewed-on: https://skia-review.googlesource.com/145529
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Chrome stopped using them in January:
https://chromium-review.googlesource.com/c/chromium/src/+/832593
For them, it significantly accelerated goma builds. From my tests,
I think we'll see some small speedup. Note that our older build
system invoked through CMD, which limited us to 8k of command line.
GN/ninja don't do that, so we have the full 32k limit. However,
we do use CMD to do our 32-bit builds... But that doesn't matter,
becase AFAICT the longest command line we generate right now is
only about 2.5k long.
Note that (like Chromium) this continues to use rsp files to link.
Those command lines *can* become ridiculously long.
The original motivation, and a nice benefit of this change:
It makes the output of ninja's compdb tool much more useful.
That tool emits JSON in a standard format describing the commands
used to build each source file. Other tools (eg Visual Studio Code)
can parse that JSON, and deduce the correct defines and include
paths to help with symbol navigation.
Change-Id: I73124f13d5117a0c31445cf6ce1c506d2f73609f
Reviewed-on: https://skia-review.googlesource.com/142584
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
We expect .BAT and .EXE to be on PATHEXT. Also, although Python
CreateProcess doesn't honor PATHEXT, it will try .EXE. This allows most
commands to be platform-independent, and also resolves the issue with
the cpython package not including python.bat.
No-Tree-Checks: true
Docs-Preview: https://skia.org/?cl=135626
Bug: chromium:852581
Change-Id: Iab4189407df44ff4ad4d37da07ff52414229d397
Reviewed-on: https://skia-review.googlesource.com/135626
Commit-Queue: Ben Wagner <benjaminwagner@google.com>
Auto-Submit: Ben Wagner <benjaminwagner@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Pass extra assembler flags to the asm tool in msvc toolchain
My first commit so added my name to the AUTHORS file.
Change-Id: I19529a901be6d9c00df3c0880003be3363475c6e
Reviewed-on: https://skia-review.googlesource.com/114740
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Enable /arch:SSE2 for Win x86 builds (both MSVC and Clang).
Change-Id: I0618e938b6542b60fae3947b7e0dcde22650ba54
Reviewed-on: https://skia-review.googlesource.com/56721
Commit-Queue: Ben Wagner <benjaminwagner@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Motivation: building for android on windows was failing for me.
Change-Id: Ia74bb99331edbe2cc9b0281e4c9ff7bbc00b08e6
Reviewed-on: https://skia-review.googlesource.com/106262
Reviewed-by: Hal Canary <halcanary@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
'windk' is no longer a thing. There are two separate variables to point
at your compiler (win_vc), and SDK (win_sdk).
'msvc' is no longer a thing, either. By default, we look for 2017 and
then 2015 (in the default locations). If neither is located, use an
assert to let users know they should set win_vc. Then, detect if win_vc
points at a 2017 or 2015 installation, and configure it automatically.
Because the toolchain is now 2017, update the GN files to handle building
x86 in that configuration. In fact, we only support x86 builds (with 2017
or 2015) using the toolchain assets. Keep a 2015 toolchain around as a
new asset, so we can add bot coverage.
Docs-Preview: https://skia.org/?cl=81841
Bug: skia:
Change-Id: I8c68a6f949e54c0e798a219450bbb9406f8dc6ac
Reviewed-on: https://skia-review.googlesource.com/81841
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Brian Osman <brianosman@google.com>
To make this simpler in the future, add a python script that finds the
most recent 2017 toolchain, and use that. If/when we update the bot
toolchain, this will be even more helpful, because the Chromium toolchain
isn't perfectly in sync with the general update channel, so people are
likely to have a newer/older release locally.
Note that explicitly setting win_toolchain_version in your GN args
suppresses the python script, so you can choose to build with whatever
version you need.
Bug: skia:
Change-Id: Iaf6d0dd9be2623472118c3ad27b20023a205d67c
Reviewed-on: https://skia-review.googlesource.com/81162
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Bug: skia:
Change-Id: I0433105c4a0e064e5cc228b7f6bec1ef3c66909c
Reviewed-on: https://skia-review.googlesource.com/62744
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Change-Id: Ib8f4d6c41356cf0fe2e14b7bff7713d107eaa01f
Reviewed-on: https://skia-review.googlesource.com/40687
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Jim Van Verth <jvanverth@google.com>
1) Run python bin/fetch-clang-win
2) Set clang_win = "../bin/clang_win"
3) ???
4) Profit
Most changes here are to pass the right -mfoo flags to Clang
to enable advanced instruction sets, or fixed warning-as-errors.
BUG=skia:2679
Change-Id: Ieed145d35c209131c7c16fdd3ee11a3de4a1a921
Reviewed-on: https://skia-review.googlesource.com/28740
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: Iaecae142dcf268517f8918d9f4fa6a64db194fab
Reviewed-on: https://skia-review.googlesource.com/23942
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
This is mainly for getting ready to start adding lots of metal backend code.
I've also update the "gpu tools" target to require ARC with involved updating
one IOS file in there.
Bug: skia:
Change-Id: Ied22e8fe7532445cc274efb529e3450654a6614b
Reviewed-on: https://skia-review.googlesource.com/22484
Commit-Queue: Greg Daniel <egdaniel@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This reverts commit c070939fd1.
Reason for revert:
This has some knock-on effects in the generation of Android.bp from our GN files. See gn/gn_to_bp.py? We're seeing things like "tmp/tmpsBVycx/gen/" end up in the include search path in Android.bp, which obviously don't exist there...
Original change's description:
> Re-land sksl fragment processor support
>
> This reverts commit ed50200682.
>
> Bug: skia:
> Change-Id: I9caa7454b391450620d6989dc472abb3cf7a2cab
> Reviewed-on: https://skia-review.googlesource.com/20965
> Reviewed-by: Ben Wagner <benjaminwagner@google.com>
> Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
TBR=benjaminwagner@google.com,ethannicholas@google.com
Change-Id: I502486b5405923b322429219f4cc396a45a14cea
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:
Reviewed-on: https://skia-review.googlesource.com/20990
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Bug: skia:
Change-Id: Ia3b0305c2b0c78074303831f628fb01852b90d34
Reviewed-on: https://skia-review.googlesource.com/17843
Commit-Queue: Ethan Nicholas <ethannicholas@google.com>
Reviewed-by: Ben Wagner <benjaminwagner@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
