Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
So far, we did not export ["@", "grpc", "", "grpc++_codegen_proto"]
and ["@", "grpc", "src/compiler", "grpc_cpp_plugin"]. Those targets
where used implicitly in the generation of protobuf. As flexible
config we use all variables those targets currently depend upon.
This will have to be extended once cross compilation will be
added. So far, the "TARGET_ARCH" is only used by targets that have
different source files (typically inline assembly) for different
target architectures. With cross compilation, also the tool chain
will depend on the target architecture.
|
|
|
|
In particular, also add a target that explicitly all dependencies
besides python3 and the C++ compiler which also serves as a machine
checkable documentation.
|
|
For quick development, it is convenient to only need a C++ compiler
and python3 and get all dependencies downloaded at the beginning
of the bootstrap process. For packaging the tool, however, this
is not a valid approach; dependencies should be managed by the
packing tool there (so that security updates have to be fixed only
at one place). So, for building our tool, the dependencies look
like installed to the ambient environment.
|
|
|
|
... which is required for boringssl, libg2 and grpc.
|
|
|
|
|
|
In this way, we follow our own standard practices of exporting
targets to be used by other repositories. While for a couple of
proto files, there shouldn't be a difference in performance, it is
still good to have the interfaces cleaned up and documented.
|
|
|
|
|
|
|
|
... and headers should be treated as headers.
|
|
... supporting trigger_on_parse() option, which allows to
call option functions multiple times, instead of collecting
the option values in a vector and processing this vector.
|
|
We assume that the git2 directory in the include-file path is
owned by git2 and no other targets put files there. Document this
by closing it up as a tree. (As a side effect we pass around fewer
identifiers and reported runfiles list get easier to read.) Note
that for the tree we can't use the TREE constructor, as, besides
the source files, there is also a generated file contained in that
directory.
|
|
|
|
As our default (bundled) bootstrap brings a well defined version of
ssl, use this also in the initial bootstrap step.
|
|
Since in default (bundled) bootstrap, we bring our own version
of libgit2, also use that for the initial bootstrap step.
|
|
The idea, as documented, of a header directory is to have a
directory, closed as a tree, owned by the respective library and
internally handled in an efficient way (as a single tree). If we
open up that directory, we just have staged data, and therefore
should treat it as such.
|
|
... instead of naming every single file. This will, on the one
hand keep the targets file more readable and, on the other hand
more easy to maintain.
|
|
... so that they become fully content-fixed and we can benefit from
target caching, once implemented.
|
|
By having a proper rule for CC/IDE, these targets are no longer
needed
|
|
This is useful when e.g. using an IDE to get access to the definition/
declaration of the symbols of external dependencies
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... and remove unused CC proto library target.
|
|
... allowing to run simple tests given by a shell script.
|
|
This is the initial version of our tool that is able to
build itself. In can be bootstrapped by
./bin/bootstrap.py
Co-authored-by: Oliver Reiche <oliver.reiche@huawei.com>
Co-authored-by: Victor Moreno <victor.moreno1@huawei.com>
|