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 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.
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.
This required putting Queue::Submit on QueueBase which is something we
would want to do anyway, and removes the need for Queue::ValidateSubmit
being called in the ProcTable.
This removes the need for all the "GeneratedCodeIncludes" files and
leads to a bunch of simplifications in BindGroup as well as the
dawn_native CMakeLists.txt.
Finally this was done in order to simplify the writing of BUILD.gn
files.
Also moves the TerribleCommandBuffer to utils:: because it isn't part of
the implementation of the wire, renames dawn::wire to dawn_wire, moves
src/wire to src/dawn_wire and puts the interface of dawn_wire in
src/include/dawn_wire.
The dawn.h and dawncpp.h structure definitions references dawnFoo or
dawn::Foo respectively when it should reference dawn_native::FooBase* in
dawn_native. Autogenerate files to declare the dawn_native version of
the structs and change the ProcTable generation to use it instead.
This is important to make libdawn_native a shared library because
currently it was depending on dawncpp's definition of .Get().
libdawn will be one of the libraries produced but other libraries like
libdawn_native don't need to link against it. However they do need the
Dawn headers so we generate them separately.
This also makes all internal targets depend on the header generation and
have the include directories necessary for those headers.
Also has a small fix for setting compile flags only for C++ files.
Methods, when their arguments are stored in a structure, are very
similar to structures (duh?) Take advantage of this to factor the
[de]serialization code between them and not just memcpy structures
around. This will allow structures to contain objects, and pointers to
other structures / array of objects etc.
The templates will live in the Chromium prototype. This also removes
the blink/ prefix from the Blink template filenames as this won't be
present in anymore.
* clang/gcc: enable -pedantic warnings
* suppress a GCC-specific warning in stb_image
* And some clang-specific warnings
* -Wconversion (clang) -Wold-style-cast (clang+gcc)
and fix a few warnings that show up with these (and a few more with
-Wconversion on gcc, even though that's not enabled by default)
* bunch more warnings
* fixes
* remove merge error
This adds support for "natively defined" API types like callbacks that
will have to be implemented manually for each target language. Also this
splits the concept of "native method" into a set of native methods per
language.
Removes the "Synchronous error" concept that was used to make builders
work in the maybe Monad, this will have to be reinroduced with builder
callbacks.
Corentin Wallez
Kai Ninomiya
Austin Eng
Kai Ninomiya