This looks like a no-op, because we're just moving flags from cflags_cc
to cflags_objcc, and then removing cflags_cc from the compiler command.
However: GN is very specific about which flags it expects to be used by
the toolchain for each file type. It ONLY emits cflags_cc into ninja
files if there is at least one C++ source file in the target. If we had
a target that only contained .mm source files, cflags_cc would be empty
and the various flags it contains would be missing. Note that ninja
silently leaves undefined variables as empty, making this not obvious.
Bug: skia:13272
Change-Id: I8d729699b1bd34b677ec1b657bc34111fa8db2a4
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/534763
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
We were generating .so files, but expect the outputs to be .dylib
(in places where we dlopen, etc.). Further, the file-type of the
libraries was actually DYLIB, not BUNDLE.
This fixes an issue with ANGLE-on-Mac, where we couldn't find libEGL,
and that (in turn) couldn't find libGLESv2.
Bug: skia:13040
Change-Id: I5eb212b9f19698cf0e0459df8ba70e62e87f5a4c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/534558
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This is a reland of ecac712bec
Changes (best viewed comparing PS1 to latest)
- Use emsdk 3.1.3 which includes important bug fixes
- Remove unnecessary steps in compile.sh
- Fix use of various gn args.
- Avoid conflicts with Flutter's GN symbols
- Add/update docs
- Make activate-emsdk script compatible with our infra.
Original change's description:
> Build CanvasKit using GN/Ninja
>
> Build with
>
> ./bin/gn gen out/wasm_debug '--args=target_cpu="wasm"'
>
> or
>
> ./bin/gn gen out/wasm_release '--args=target_cpu="wasm" is_debug=false'
>
> Change-Id: Ib74586bf8397d57064a3899eaa6da76f9bce9049
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/502036
> Reviewed-by: Kevin Lubick <kjlubick@google.com>
> Reviewed-by: Ben Wagner <bungeman@google.com>
Change-Id: I601712a8953c2799fa029e782e097905b95e6b59
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/507717
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Build with
./bin/gn gen out/wasm_debug '--args=target_cpu="wasm"'
or
./bin/gn gen out/wasm_release '--args=target_cpu="wasm" is_debug=false'
Change-Id: Ib74586bf8397d57064a3899eaa6da76f9bce9049
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/502036
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
This is a recent addition to GN that Dawn takes advantages of but which
Skia's GN toolchain didn't implement yet.
Bug:
Change-Id: I7a592bd4663db5c9726767bedf46c38d9c86ed2e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/307576
Commit-Queue: Corentin Wallez <cwallez@chromium.org>
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
The oss-fuzz build of Skia seems to have difficulty when it does too
many linker steps at a time. Ninja will generally not launch new build
steps if the load is too high, but the oss-fuzz builder machines are
slow enough that the load doesn't seem to rise fast enough to prevent
too many linkers from be started at a time.
By default this change does not request a linker pool at all and the
user must request one by setting the link_pool_depth. Negative values
disable the linker pool, zero sets the number to the number of cpus, and
positive values set the pool size. This should allow for some
experimentation while testing what pool size is appropriate for the fuzz
builders while not changing current default behavior.
Bug: oss-fuzz:23438,oss-fuzz:24345
Change-Id: Iba62adac3bea4d968441aa08e33918b5ae962c7b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/306646
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Use $shell prefix invoking python for cp.py.
Change-Id: Ic4b40337255a91fe6f9729eb58ecb6d47c559001
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/306334
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This reverts commit c61e35dbc6.
Reason for revert: Breaking builds
Original change's description:
> Switch GN defs on Mac and iOS to use frameworks instead of libs.
>
> GN will be removing support for frameworks in the libs variable, so
> might as well get ahead of it.
>
> Change-Id: I67b118457721975ac2408308438d71172be66592
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300181
> Commit-Queue: Jim Van Verth <jvanverth@google.com>
> Reviewed-by: Mike Klein <mtklein@google.com>
TBR=mtklein@google.com,jvanverth@google.com
Change-Id: I7b81a92a67181e08ee57bcb184768794281cd37a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300228
Reviewed-by: Jim Van Verth <jvanverth@google.com>
GN will be removing support for frameworks in the libs variable, so
might as well get ahead of it.
Change-Id: I67b118457721975ac2408308438d71172be66592
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/300181
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
The ar utility only adds symbols. As a result removed symbols are
sometimes still present in later builds, leading to great confusion.
Delete the .a file before recreating it with ar.
This is similar to what Chromium currently does in gcc_toolchain.gni.
However, we cannot always just use 'rm' because of the build for Android
on Windows, so this introduces 'rm.py' which is just like 'cp.py' but
without the copy part.
Bug: skia:10363
Change-Id: Icc0c3d18dab1e48ccfec47386662c7b4d2dc8811
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/295569
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This reverts commit 3b035e0417.
Reason for revert: Build-Win-Clang-arm64-Release-Android runs on
Windows and uses llvm-ar.
Original change's description:
> Delete .a file before writing static library.
>
> The ar utility only adds symbols. As a result removed symbols are
> sometimes still present in later builds, leading to great confusion.
> Delete the .a file before recreating it with ar.
>
> This is similar to what Chromium currently does in gcc_toolchain.gni.
>
> Bug: skia:10363
> Change-Id: I133deb6da570ca38a539b4f0bb486b61d6a664bf
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/295217
> Reviewed-by: Mike Klein <mtklein@google.com>
> Commit-Queue: Ben Wagner <bungeman@google.com>
TBR=mtklein@google.com,bungeman@google.com
Change-Id: I02ba93ce26eedb2b2362e96d2ebfcacbfb8e0902
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:10363
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/295445
Reviewed-by: Ben Wagner <bungeman@google.com>
The ar utility only adds symbols. As a result removed symbols are
sometimes still present in later builds, leading to great confusion.
Delete the .a file before recreating it with ar.
This is similar to what Chromium currently does in gcc_toolchain.gni.
Bug: skia:10363
Change-Id: I133deb6da570ca38a539b4f0bb486b61d6a664bf
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/295217
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
This prevents a build failure if Skia is installed to a path with a space in it.
Change-Id: I3f9a6d435971720a32c3ac14c9eb144f2da563a3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280183
Auto-Submit: John Stiles <johnstiles@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: I2d19c4f0ff1439dcd923a3064eb3ba78432a5113
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/281043
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Change-Id: I0d94bf055413ab7911136256f2ce2cda3581f45a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/275656
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Change-Id: Ie951106bbd7a91dd76b30a56ede9313c88e657ab
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/260499
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Eric Boren <borenet@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
if a filename ends with `.py` and the file begins with '#!.*python.*',
make it executable.
Change-Id: I41de516ff37343d3b0979bde9fd61813aec7365c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/254439
Commit-Queue: Hal Canary <halcanary@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Auto-Submit: Hal Canary <halcanary@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
Change-Id: I2619784eca0f7a4dd66f2db0104cb746d9266b4e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/244369
Commit-Queue: John Rosasco <rosasco@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
This is what I was getting at on the comments in PS 5.
Change-Id: I5435860ebea9ed01217d7acb378e1fadce19b107
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/250776
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
From mac's man libtool
Libtool with -static is intended to replace ar(5) and ranlib
Libtool allows RSP files, and has -no_warning_for_no_symbols
Change-Id: I1d61095db02ae83fdf491c26eae7d9d4cefc2d17
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/250337
Commit-Queue: Herb Derby <herb@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
dsymutil seems to kill the machine when too many processes are run in
parallel, so we need to use a pool to limit the concurrency when
passing large -j to Ninja (e.g. Goma build).
Change-Id: I84404291db4781f86268256ab888cef8d07c770e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/234477
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Auto-Submit: Ben Wagner aka dogben <benjaminwagner@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Change-Id: I18a3bd5e845305e3b2521d076fd641bd5175b618
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/234327
Commit-Queue: Jim Van Verth <jvanverth@google.com>
Auto-Submit: Ben Wagner aka dogben <benjaminwagner@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Change-Id: I81835ffdd1fbdaa12d662527e38b42532f2ea8e8
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/238756
Commit-Queue: Hal Canary <halcanary@skia.org>
Reviewed-by: Brian Osman <brianosman@google.com>
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>
