| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|