Drop libprotobuf dependency and update compile_perfetto_protos
to rely on externally provided protoc and protozero_plugin.
This is done because protoc does not build with our current
toolchain and fixing this build requires rolling new protobuf,
protobuf_gn and perfetto. Which also pulls more external dependencies
like abseil.
Regenerate Perfetto *.pbzero{.cc,.h}, *.dart files
TEST=ci
Change-Id: I11a32aa07e810b48ac12502e526bbaee6a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482781
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This CL tries to address version skew issues which occur in internal
monorepo which we created by checking in *.pbzero.h files into
runtime/vm/protos/*. These files refer to protozero internal headers,
which in the internal monorepo come from a shared Perfetto dependency
which does not necessarily match the version we pinned in our DEPS and
used to generated these files.
This version skew caused problems for the Perfetto team, see
https://github.com/google/perfetto/pull/3195
To resolve this change layout of our repo to allow us to depend on the
shared Perfetto entirely - including its version of *.pbzero.h headers.
We change include paths in the VM source to
#include "third_party/perfetto/protos/..."
which match location of these headers in the internal monorepo.
To make the code compile in the normal SDK checkout we shift location of
Perfetto and checked in code:
* Perfetto source moves from third_party/perfetto to
third_party/perfetto/src.
* Generated code moves from runtime/vm/protos into
third_party/perfetto/protos.
Note: experiments show that *.pbzero.h files tree-shake very well and
you pay only for things that you use. That means depending on *.pbzero.h
files generated from full message definitions rather than our manually
tree-shaken versions does not actually increase the size of the VM
binaries. We could switch our external build to do the same but this
would make protoc a build time dependency, which seems excessive.
TEST=ci
Change-Id: I724b9d9304be83302a5d83c2337154b36a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/454260
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
- `build/mac/find_sdk.py` can search for iPhone and Watch SDKs and their simulators
- `tools/build.py` supports `--os=ios` and `-os=ios_simulator` now. Treating simulator as a separate os to minimize changes and avoid an additional dimension for configs.
- `vm-mac-(release|debug)-arm64-try` tryjobs make sure a shared library builds successfully for ios.
TEST=ci
Change-Id: I76358ec8fd33752260bf0b8462da22a13cd7562e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/381623
Auto-Submit: Ivan Inozemtsev <iinozemtsev@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This change:
- Sucks in gn binaries
- Sucks in a version of llvm that the GN build likes
- Adds tools/gn.py to invoke gn
- Adds a root BUILD.gn and .gn file
- Removes chrome boilerplate we don't need
- etc.
This lets us do a standalone build of the 'runtime'
target for x64, ia32, arm, arm64, mips, and the
simulators on Linux, and arm and arm64 on Android.
It does not include tcmalloc, and hasn't been tested
on Mac or Windows. That work and more cleanup of
chrome boilerplate will come in follow-up CLs.
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org/2350583002 .
Slava Egorov