[bazel] Confusion about gen_reflections in flatbuffer_cc_library bazel rule

[andrewwongagility]

I'm wondering if setting gen_reflections = True in the flatbuffer_cc_library` bazel rule defined here, should generate *.bfbs files. I've included a snippet of my BUILD file below:

FLATC_ARGS = [
    "--gen-object-api",
    "--gen-mutable",
    "--scoped-enums",
]

# TODO: gen_reflections does not appear to generate .bfbs files
flatbuffer_cc_library(
    name = "foxglove-flatbuffers",
    srcs = glob(["*.fbs"]),
    flatc_args = FLATC_ARGS,
    gen_reflections = True,
    out_prefix = "foxglove/flatbuffers/",
)

After building a target that relies this rule, I could not find any files with the *.bfbs extension. I did see that the headers *_generated.h were successfully output to the foxglove/flatbuffers/ folder

Thank you for any help!

[jameskuszmaul-brt]

gen_reflections should work; however, if you look at how the flatbuffer_cc_library macro is implemented, you will see that it actually defines a separate rule for the reflections. So you need to depend on/build the foxglove-flatbuffers_reflection_out rule, not the foxglove-flatbuffers rule. If you run a bazel query //path/to/package/... you can see all the rules generated by a given macro.
You can see an example repo using the foxglove flatbuffer schemas at https://github.com/frc971/971-Robot-Code/blob/4ff0ec9d3fecd951efa87757163de45a9d3b785b/third_party/foxglove/schemas/schemas.BUILD -- and do let me know if you have any other issues, since I have a vested interest in ensuring that both the flatbuffers bazel rules and the foxglove <-> flatbuffers integration work.

[andrewwongagility]

@jameskuszmaul-brt Thank you for your quick reply! I tried changing @foxglove-flatbuffers to @foxglove-flatbuffers_reflection_out in the BUILD file that depended on foxglove flatbuffers, but bazel could not find that rule

I'll also try to emulate the structure of the repo you linked to

[jameskuszmaul-brt]

That's not how bazel build rule naming works--you probably meant to depend on @foxglove-flatbuffers//:foxglove-flatbuffers_reflection_out. Do a bazel query @foxglove-flatbuffers//... to see what rules you have available. See https://bazel.build/concepts/labels

[andrewwongagility]

@jameskuszmaul-brt Thank you very much for your help and patience!

I tried adding @foxglove-flatbuffers//:foxglove-flatbuffers_reflection_out to deps of the cc_library, but Bazel said this was not allowed. I ended up adding @foxglove-flatbuffers//:foxglove-flatbuffers_reflection_out to data of the cc_library:

# /my/code/BUILD which depends on @foxglove-flatbuffers
cc_library(
    name = "SensorDataRecorder",
    srcs = ["SensorDataRecorder.cpp"],
    hdrs = ["SensorDataRecorder.hpp"],
    # Required to generate *.bfbs schema files
    # TODO: separate out definitions of schemas, so unused schemas are not generated?
    data = ["@foxglove-flatbuffers//:foxglove-flatbuffers_reflection_out"],
    deps = [
        "@foxglove-flatbuffers",
        "@mcap",
        ...
    ],
)

This generated all *.bfbs files corresponding to foxglove flatbuffer (*.fbs) files.

For PointCloud.bfbs, the generated file path is: /bazel/out/k8-opt/bin/external/foxglove-flatbuffers/foxglove/flatbuffers/PointCloud.bfbs and the file could be accessed in my C++ code as: external/foxglove-flatbuffers/foxglove/flatbuffers/PointCloud.bfbs

This may not be ideal, since bazel generates all *.bfbs files although we only need a few *.bfbs files. However this was a method I found that worked. Please feel free to suggest something better.

Thanks again for all your help!

[jameskuszmaul-brt]

1. Using data, not deps, is correct in this case--you can read up more on this at https://bazel.build/concepts/dependencies#types-of-dependencies, but basically deps are the C++ libraries you want to depend on, data are the things that your C++ code will need at runtime.
2. Yes, it will generate all the .bfbs files in this case. It's possible to make it more selective, but then you have to create a separate flatbuffer_cc_library for every .fbs schema. Unless there is a problem with generating the extra .bfbs files, I wouldn't worry about it.