To detect and rebuild all TUs on toolchain updates, we inherited a rule from
Chromium whereby the Git SHA of the //buildtools repo would be used to insert a
preprocessor define in each TUs build invocation. But we don't use a
//buildtools as a repo anymore. Instead buildtools comes from CIPD. So the
script now picks the //buildroot revision instead. But we don't specify the
toolchain revision in that repo either though. It is instead specified in the
engine. So if the engine updates the toolchain, only the next (unrelated)
//buildroot rev will ensure all old TUs are rebuilt unless the `out` directory
is cleared on each invocation.
This patch replaces the old buggy technique with one where the system headers
(that include headers in buildtools) are tracked in addition to user headers.
When the toolchain updates, these "system" header timestamps will be invalidated
and the old artifacts invalidate.
The simple change of just tracking the //flutter (where the toolchain SHA is
present) would make it so that each engine change (frequent) would rebuild all
TUs instead of just each buildtools change (rarer). Also, this technique would
leave us susceptible to the kind of issue that led us in this situation in the
first place.
I also just searched and replaced all calls to track user dependencies with ones
to track system + user dependencies. Not all toolchain are actually being used.
We should clean these up in a separate patch.
The following changes have been made:
* In //build/fuchsia/sdk.gni: fuchsia_sdk has been renamed to fuchsia_sdk_root.
* //build/fuchsia/sdk.gni is no longer implicitly imported and must be imported by GN files explicitly once the is_fuchsia check is done.
* Since SDK part names are not guaranteed to be unique, the sysroot, fidl and CC parts are each put in their own directories.
This prepares the buildroot to stamp GN targets for Fuchsia SDK defined targets.
GN templates have been created in //build/fuchsia/fuchsia.gni that
can read the JSON metadata that describes the vended SDK.
GN targets that describe all known SDK parts (as described in the SDK
manifest) can be instantiated in one shot by defining a top level fuchsia_sdk
target. This stamping needs to happen once and can be done anywhere (currenly
in //build/fuchsia/BUILD.gn). Once stamped, targets that depend on
specific Fuchsia SDK parts need to explicitly depend on them by using the
name of that part. For example, depending on the :fuchsia.images part of the
SDK will generate headers for all fidl files in that part, compile any source
libraries and link the required dynamic libraries into the executable. Unlike regular
targets, this target does not exist in a GN file. The name must be looked up
from JSON manifest. This scheme seems to work well but is not resilient
to part name collision.
So that SDK and non-SDK Fuchsia builds may co-exist till the migration is done,
the is_fuchsia_sdk GN variable and FUCHSIA_SDK preprocessor defines are
set in all Fuchsia SDK builds. This allows code to target both variants. It is
the hope that the non SDK variant will be turned down and the Flutter team
assumes ownership of this component.
