| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Build zlib with grpc's add_subdirectory
* Build grpc and its children with add_subdirectory.
* Build c-ares with grpc's add_subdirectory
* Convert protobuf to a download-only ExternalProject
* Temporarily break protobuf within grpc
This works because libgrpc has no actual dependency on protobuf
* Update boringssl to master@{2018-07-10}
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* Add a download-only boringssl ExternalProject
Match boringssl version to grpc submodule version
* Split grpc into separate download and build tasks
This allows other external targets to download into the gRPC source tree
before grpc is actually built.
* Convert grpc to an http download
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Pull out sanitizer options into a separate file
* Reorder packages
* Remove the extra "external/$target" directory from PREFIX
Instead of BINARY_DIR/external/foo/src/foo the contents will be in
BINARY_DIR/src/foo.
* Make libprotobuf-nanopb targets line up with nanopb's CMakeLists.txt
* Fix CMake style
|
| |
|
|
|
|
|
|
| |
* Add cmake dependencies where required
... instead of relying on a topological sort in the top-level
CMakeLists.txt.
* Add early exits to external project builds
|
| |
|
|
|
|
|
|
|
|
|
| |
* Add an external build for c-ares
* Use installed c-ares package configuration
* Adjust protobuf configuration to use the standard Protobuf_DIR variable.
* Have grpc depend on c-ares
* Drop UPDATE_COMMAND where it doesn't matter
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Install protobuf
* Use the built-in FindProtobuf.cmake
* Add additional build configuration flags
* Preserve generator configuration in the protobuf sub-build
Without this, the build fails on Win64 because the default
configuration builds a Win32 libprotobuf and the Win64 build rejects
it.
* Wire the installed protobuf into the gRPC build.
* Install nanopb
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Build protobuf with CMake for compatibility with Windows.
Fixes b/74067357
* Update to nanopb 0.3.9.1
This release includes functional CMake support for building the protoc
plugin.
* Fix license
* Build nanopb out-of-source
This is possible now that the build is CMake-based.
* Find protoc on windows
* Define CMAKE_ARGS in a more straightforward way
* Adjust libprotobuf locations to account for CMake build
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Build (grpc's) nanopb with -DPB_FIELD_16BIT
We require (at least) 16 bit fields. (By default, nanopb uses 8 bit
fields, ie allowing up to 256 field tags.)
Also note that this patch adds this to grpc's nanopb, rather than to our
nanopb. We'll need to eventually either:
a) we instruct grpc to use our nanopb
b) we rely on grpc's nanopb instead of using our own.
(^ marked as a TODO for now.)
* Add some dependant protos
Imported from protobuf. Nanopb requires these to be present (though
anything using libprotobuf does not, as these are already built into
that.)
* Add generated nanopb protos based off of newly added proto definitions
* Build the nanopb protos
* Serialize and deserialize null
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We check them out from a git tag, so this *should* be a noop. However,
cmake seems to want to rebuild these dependencies every time you run
make as it assumes the dependency *might* have been updated. (In
practice, this isn't completely awful, as make notices the files haven't
changed, so files don't actually get recompiled. But the configure step
is still re-run and all the files still need to be rescanned.)
Skipping the update step speeds up the build considerably.
On my linux box, running:
cmake .. && make -j && time make -j
takes ~8.5s prior to this CL and ~6.5 afterwards. (6s is used by the
test suite.) The upcoming protobuf addition would otherwise have made
this much worse. (It takes a long time to ./configure.)
|
| |
|
|
|
|
|
|
|
|
|
| |
We originally had this as it was thought that cmake would spawn n*m jobs
(where n is the number of jobs it was instructed to create, ie. make
-j8, and m is the number of external projects.) However, it isn't
supposed to do that, and doesn't appear to be doing that right now. So
we'll remove this.
If the problem re-appears, we'll add these back in. (Symptom was being
unable to spawn /bin/sh.)
|
|
|
* Clean up quoting and other minor issues
* Reorganize CMake build output
Make it clearer which parts of the output pertain to external projects.
* Use a consistent ordering of ExternalProject arguments
* Prevent the top-level build from running in parallel
This prevents spurious failures when running make -j.
* Actually parse arguments in the xcodebuild function
* Use ExternalProject features when available
* submodule limits from CMake 3.0
* shallow clones from CMake 3.6
* git progress output from CMake 3.8
* Only build the parts of leveldb we need
Skip building the tools and other libraries
* Avoid installing ExternalProjects
Consume build output directly so that we can build just the targets we
need. Installing causes all targets to be built.
This doesn't matter as much for these targets but the gRPC build
includes a ton of stuff we don't need so it's worth adopting this as a
general strategy.
* Define an external build for grpc
* Test that grpc can link successfully.
* Add a FindGRPC CMake module
* Actually comment ExternalProjext_GitSource
|
Gil
rsgowman