rpc_generated and CMAKE_BUILD_TYPE
dotnwat opened this issue · comments
I recently noticed that on release builds the rpc_generated.h
file is produced using 64-bit types here:
https://github.com/smfrpc/smf/blob/master/src/include/smf/rpc_generated.h#L630
And with a debug build the same is produced with a 32-bit type. Oddly, it looks like 64-bit is hardcoded in the flatbuffers idl generator.
I'm wondering if anyone has seen this before I go looking deeper.
Wild. Haven't seen this. Definitely a bug. So the issue is if you invoke flatc
in debug mode it produces 32bit ints! that's wild.
I checked the code and it seems only 64 bits are generated.
if (!vs.empty()) {
code_ += " static const int64_t values[] = { {{VALUES}} };";
}
Seems to have been introduced in this change: https://github.com/google/flatbuffers/pull/4944/files
Thanks. That led me to this which I think is the source of the 32-bit integers: https://github.com/google/flatbuffers/blame/a4c362a1ba539ecb846b6b8c999d9b3522f8c1c6/src/idl_gen_cpp.cpp#L866
And the actual problem appears to be that with smf debug builds my system-level install of flatc
which is older is being invoked rather than the flatc
binary built as a dep.
oh that seems bad w.r.t flatc. We'll probably need to change the call to find programs lookup path to first look in the CMAKE_BINARY_DIR/smf-deps/bin
before looking in PATH
- Do you want to rename the issue to reflect that? or we can fix it in the cooking removal pr.
let's leave this open for now--ill revisit the issue tonight, or tomorrow. it'd be kinda dope to figure out how to sandbox the builds, but running them in a minimal docker image is probably good enough. running a debug in ci/build-in-docker.sh should verify the issue.
looks like upgrading flatbuffers is in order. this seems to be the source of the issue https://github.com/google/flatbuffers/blob/b99332efd732e6faf60bb7ce1ce5902ed65d5ba3/CMakeLists.txt#L395
The fix isn't in the latest release, but it is in master. What do you think? Use flatbuffers@master or only build release versions of flatbuffers until a new release?
I regularly use master commits from flatbuffers tho. Let's do it, let's pull in the latest flatbuffers.
@noahdesu can we close this?
please close if you think is fixed ( i think this is done )