1.9 KiB
1.9 KiB
Regenerating Flatbuffers code
If you have changed some *.fbs
files:
- Run
./entry/regenerate-flatbuffers.sh
to regenerate the corresponding Rust code. - Run
cargo test
to make sure everything works as you would expect. - Check in the changes to the generated code along with your changes to the
*.fbs
files. - You should not need to edit the
entry/regenerate-flatbuffers.sh
script.
If you are updating the version of the flatbuffers
crate in Cargo.lock
, either because a new
patch release has come out that is compatible with the version range in Cargo.toml
and you have
run cargo update
, or because you've updated the version constraint in Cargo.toml
to change to a
new major or minor version:
- The
flatbuffers
crate gets developed in sync with theflatc
compiler in the same repo, so when updating theflatbuffers
crate we also need to update theflatc
compiler we're using. - Go to https://github.com/google/flatbuffers/blame/master/rust/flatbuffers/Cargo.toml and find
the commit SHA where the
version
metadata was updated to the version of theflatbuffers
crate we now want to have in ourCargo.lock
. - In the
entry/regenerate-flatbuffers.sh
script, put that commit SHA in theFB_COMMIT
variable. - Run
./entry/regenerate-flatbuffers.sh
to regenerate the corresponding Rust code. - Run
cargo test
to make sure everything works as you would expect. - Check in the changes to the generated code along with your changes to the
Cargo.lock
file,Cargo.toml
file if relevant, and theentry/regenerate-flatbuffers.sh
script.
By default, the entry/regenerate-flatbuffers.sh
script will run a Docker container that
uses the same image we use in CI that will have all the necessary dependencies. If you don't want
to use Docker, run this script with INFLUXDB_IOX_INTEGRATION_LOCAL=1
, which will require you to
have bazel
available. You can likely install bazel
with your favourite package manager.