Add flatbuffer_cc library support #5061
Conversation
Tests now all pass!
This should be a simple serialize/deserialize test of the new generated code to make sure the bazel rules are doing something sane.
cmake drops it's generated code in tests/monster_test_generated.h Instead of checking that in, let's generate it with bazel.
11a2720 to
a8a3f82
Compare
CMakeLists.txt
Outdated
| grpc/tests/message_builder_test.cpp | ||
| # file generated by running compiler on samples/monster.fbs | ||
| ${CMAKE_CURRENT_BINARY_DIR}/samples/monster_generated.h | ||
| ${CMAKE_CURRENT_BINARY_DIR}/tests/monster_test_generated.h |
There was a problem hiding this comment.
You probably don't need both.
This should address @aardappel's feedback.
|
I need to figure out why the android build is failing, but other than that, it should be ready. I'm going to do that later tonight. |
This will fix the last travis.ci failure
|
I'm still struggling on the android build. Any hints would be welcome. It feels like there's a missing dependency link, but for the life of me, I don't know how to add it or find out which one is missing. |
| # Description: | ||
| # BUILD rules for generating flatbuffer files in various languages. | ||
|
|
||
| flatc_path = "//:flatc" |
There was a problem hiding this comment.
Is it possible to make this compatible when flatbuffers is put in //third_party/flatbuffers instead of registered as a bazel repository? Maybe //external:flatc, but bind is being deprecated.
There was a problem hiding this comment.
I put it in //third_party/flatbuffers in our repo. The trick is to then write:
local_repository(
name = "com_github_google_flatbuffers",
path = "third_party/flatbuffers",
)
And then everything will just work.
From what I've been seeing for the last couple of years, the trend is to use local_repository (or one of the various other ways to pull in a repository) rather than //external and bind.
There was a problem hiding this comment.
Thanks for the suggestion. I tried to avoid using sub-repo whenever a repo supports direct vendoring (used as //third_party/... instead of @...). Looks like the trend is not going that way 🤕. Also it looks like sub-repo and //third_party are different but I don't find a canonical path for these sub-repos. We currently use //vendor.
Android was the only target using the STL emulation layer. It needed the --cpp-ptr-type flatbuffers::unique_ptr flag to work. Add it!
|
Everything passes now. I can clean up the git history if that would be helpful. It was hard to test locally. |
Flip tests/test.cpp to use the autogenerated file as well.
|
@aardappel , anything else to fix, or can this be merged? |
|
LGTM, thanks! |
* Add flatbuffer_cc library support * Update flags so all the tests pass Tests now all pass! * Modify the tests to use the generated code This should be a simple serialize/deserialize test of the new generated code to make sure the bazel rules are doing something sane. * Use generated monster_test.fb in testing/test.cpp cmake drops it's generated code in tests/monster_test_generated.h Instead of checking that in, let's generate it with bazel. * Make grpc tests depend on monster_test_generated.h * Remove redundant cmake dependency This should address @aardappel's feedback. * Run flatc for Android as well This will fix the last travis.ci failure * Add generated output folder and fix flags * Move flatbuffers_header_build_rules to the library that uses it * Use --cpp-ptr-type to fix android Android was the only target using the STL emulation layer. It needed the --cpp-ptr-type flatbuffers::unique_ptr flag to work. Add it! * Roll back changes to use autogenerated monster_test_generated. Flip tests/test.cpp to use the autogenerated file as well.
Taking over #4861 Thanks @jschaf for getting most of the way there!
This PR adds starlark support to generate flatbuffers for C++. It is based off of internal Google starlark.