Chromium's BUILD files try to avoid uses of exec_script when possible
because they slow down every GN invocation. In preparation for building
Dawn inside Chromium, the calls to exec_script for the code generator
are removed.
In GN, the generator now outputs a "JSON tarball", a dictionnary mapping
filenames to content. This allows us to use the "depfile" feature of GN
to avoid the exec_script call to gather the script's inputs.
Outputs of the generator are now listed in the BUILD.gn files. To keep
it in sync with the generator, GN outputs a file containing "expected
outputs" that is checked by the code generator.
Finally the dawn_generator GN template doesn't create a target anymore,
but users are expected to gather outputs using get_target_outputs.
This includes a bunch of fixes for clang warnings in Windows specific
code that was only compiled by MSVC previously. This also tidies up some
BUILD.gn issues on Windows.
This makes the Jinja2 (and MarkupSafe) installation hermetic by
adding it to the DEPS and making the code generator add them in the
first spot of the python path.
This required adding some missing dependencies, splitting public headers
of libdawn_[native|wire] so they aren't hidden in the
libdawn_[native|wire]_sources targets, and making unittests depend on
sources directly instead of static libraries (which is almost equivalent).
As a byproduct, Empty.cpp is no longer needed and is removed.
The code generator doesn't need to load the JSON file to compute the
dependencies our outputs for a codegen target. To better integrate in
noop builds, the lazy-write of generated file is removed because it led
to the code generator running even in noop build (the timestamp of
generated file not being updated).
Also document what could be done to avoid exec_script calls for the Dawn
code generator.
Yan,Shaobo
Corentin Wallez