smfrpc / smf

Fastest RPC in the west

Home Page:http://smfrpc.github.io/smf/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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 flatcwhich 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 )