Minimal Bazel BUILD and WORKSPACE files for compiling "monster" example including sample_text.cpp

[Sean McLaughlin]

Hi,

I'm new to both FlatBuffers and Bazel.  Can anyone post a minimal example for compiling flatc itself, the monster_generated.h file, and then sample_text.cpp?

When I run:

bazel build flatbuffers:flatc

I get the following error:

Unable to find package for @rules_cc//cc:defs.bzl: The repository '@rules_cc' could not be resolved.

I then build flatc with CMake temporarily, and moved on to building sample_text.cpp with Bazel.  I thought I found a minimal example here:

https://github.com/hazelnusse/flatbuffers-bazel

However, when I run:

bazel build flatbuffers-bazel:sample_binary

I get:

fatal error: 'monster_generated.h' file not found

When I cheat and bring a copy of monster_generated.h (manually made with flatc, itself compiled with CMake) into the workspace, and add it to the srcs section of BUILD, I then get:

every rule of type cc_flatbuffers_compile implicitly depends upon the target '@flatbuffers//:flatc', but this target could not be found because of: no such package '@flatbuffers//': The repository '@flatbuffers' could not be resolved

This is probably a basic issue since it does appear that Bazel is supported, so any advice is very welcome!

Thanks,

Sean

[Wouter van Oortmerssen]

+Austin (who probably knows more)..

Confidentiality Note: We care about protecting our proprietary information, confidential material, and trade secrets. This message may contain some or all of those things. Cruise will suffer material harm if anyone other than the intended recipient disseminates or takes any action based on this message. If you have received this message (including any attachments) in error, please delete it immediately and notify the sender promptly.

--
You received this message because you are subscribed to the Google Groups "FlatBuffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flatbuffers...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/flatbuffers/141655f7-012c-47d4-b924-64aa871cbf10%40googlegroups.com.

[Sean McLaughlin]

Thanks for the reply, Austin (and Wooter for the referral).  In my case, the sample files are in the /samples subdirectory of my local repository for FlatBuffers "itself" which I cloned from: https://github.com/google/flatbuffers/tree/master/ 

So the FlatBuffers repo itself is just one level up.  So would I then point the local_repository to the parent directory, using path = ".." or similar (this all goes into the WORKSPACE file in the /samples directory)?  Or, I could copy the sample files of interest into a testing directory, and then create a "third_party" subdirectory, clone a full copy of the FlatBuffers git there, and follow your instructions as-written?

Regarding the rules_cc error, I will try this, but is this an omission in the WORKSPACE file provided on the FlatBuffers git repo?  Thanks so much!

Sean

On Thu, Feb 6, 2020 at 6:55 PM Austin Schuh <austin...@gmail.com> wrote:

You need to import flatbuffers as an external dependency.  You can
either use a http_archive, or a local_repository.

Try something like:

local_repository(
    name = "com_github_google_flatbuffers",
    path = "third_party/flatbuffers",
)

And then put the flatbuffers repo in third_party/flatbuffers in your repo.

Or, you can try something like:

http_archive(
    name = "com_github_google_flatbuffers",
    url = "https://github.com/google/flatbuffers/archive/master.zip",
    strip_prefix="flatbuffers-master"
)

(Though don't use master for anything but testing...  And you should
really add the SHA256 attribute as well.)

Then, in your BUILD file, do something like:

load("@com_github_google_flatbuffers//:build_defs.bzl", "flatbuffer_cc_library")

flatbuffer_cc_library(
    name = "test_message_fbs",
    srcs = ["test_message.fbs"],
    gen_reflections = 1,
)

cc_library(
  name = "my_lib",
  ...
  deps = [
    ":test_message_fbs",
  ]
)

This is copied from some less than trivial examples, but should be pretty close.

And for the rules_cc error, try adding the following to your workspace file:

# C++ rules for Bazel.
http_archive(
    name = "rules_cc",
    sha256 = "67412176974bfce3f4cf8bdaff39784a72ed709fc58def599d1f68710b58d68b",
    strip_prefix = "rules_cc-b7fe9697c0c76ab2fd431a891dbb9a6a32ed7c3e",
    urls = [
        "https://mirror.bazel.build/github.com/bazelbuild/rules_cc/archive/b7fe9697c0c76ab2fd431a891dbb9a6a32ed7c3e.zip",
        "https://github.com/bazelbuild/rules_cc/archive/b7fe9697c0c76ab2fd431a891dbb9a6a32ed7c3e.zip",
    ],
)


Austin

[Austin Schuh]

Ah, gotcha.

Apply this patch:

diff --git a/samples/sample_binary.cpp b/samples/sample_binary.cpp
index b8f4f1f6..e14e9e2b 100644
--- a/samples/sample_binary.cpp
+++ b/samples/sample_binary.cpp
@@ -14,7 +14,7 @@
* limitations under the License.
*/

-#include "monster_generated.h" // Already includes
"flatbuffers/flatbuffers.h".
+#include "samples/monster_generated.h" // Already includes
"flatbuffers/flatbuffers.h".

using namespace MyGame::Sample;


Add this as the BUILD file:

austin[30141] (master) ~/local/flatbuffers
$ cat samples/BUILD
load("//:build_defs.bzl", "flatbuffer_cc_library")

flatbuffer_cc_library(
name = "monster_fbs",
srcs = ["monster.fbs"],
)

cc_binary(
name = "sample_binary",
srcs = [
"sample_binary.cpp",
],
deps = [
":monster_fbs",
],
)

Then you should be able to run it!

austin[30143] (master) ~/local/flatbuffers
$ bazel run -c opt //samples:sample_binary
INFO: Analyzed target //samples:sample_binary (0 packages loaded, 0
targets configured).
INFO: Found 1 target...
Target //samples:sample_binary up-to-date:
bazel-bin/samples/sample_binary
INFO: Elapsed time: 0.174s, Critical Path: 0.00s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action
INFO: Build completed successfully, 1 total action
The FlatBuffer was successfully created and verified!

Make sure your bazel is decently modern. And to reproduce what I did,
you want to be on the latest master.

austin[30145] (master) ~/local/flatbuffers
$ bazel version
Build label: 2.0.0
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Thu Dec 19 12:30:18 2019 (1576758618)
Build timestamp: 1576758618
Build timestamp as int: 1576758618

The background here is that bazel really really wants to use absolute
paths in your repo, which is sometimes at odds with flatbuffers. I've
been running with the following arguments (build_defs.bzl), which is
different than the defaults.

DEFAULT_FLATC_ARGS = [
"--gen-object-api",
"--gen-compare",
"--keep-prefix",
"--gen-mutable",
"--reflect-names",
"--cpp-ptr-type flatbuffers::unique_ptr",
"--force-empty",
"--scoped-enums",
"--gen-name-strings",
]

Somewhere on my long TODO list is to rewrite the bazel rules for
flatbuffers to not be genrules.

load("@com_github_google_flatbuffers//:build_defs.bzl", "flatbuffer_cc_library")

will load it from an external repo when you are ready. And then the
rest of the build file should work.

Austin

[Sean McLaughlin]

Thanks again Austin! I guess we enforce something like a monorepo at my company, and the WORKSPACE file in FlatBuffers got ignored.  I was able to get flatc to build simply by making a com_github_google_flatbuffers entry in the root WORKSPACE file for our company, and doing a repo_mapping for rules_cc.  (If I merged in FlatBuffers to our git repo, I'd want to minimize exposing rules_cc without asking...)

However, although I could get flatc to compile, I couldn't compile the included tests.  I had to make the following change (and a similar one for reflection_genrule_cmd) to get the tests working:

    genrule_cmd = " ".join([
        "SRCS=($(SRCS));",
        "INC=\"\";",
        "for i in $${SRCS[@]:%s:%s}; do" % (len(srcs), len(includes)),
        "INC+=\" -I $$(dirname $$i)\";",
        "done;",
        "for f in $${SRCS[@]:0:%s}; do" % len(srcs),
        "$(location %s)" % (flatc_path),
        " ".join(include_paths_cmd),
        "$$INC",
        " ".join(flatc_args),
        language_flag,
        output_directory,
        "$$f;",
        "done",
    ])

Anything involving "INC" (includes) is my code.  Maybe this wouldn't be necessary if building FlatBuffers at the root of a workspace (I assume someone has tested the tests w/o problems...!) but this isn't allowed for us.  This also saves ever having to specify include paths explicitly - the whole option could be removed.  Hope it helps somebody.  It was definitely a useful Bazel learning exercise.

Sean McLaughlin Associate Software Engineer Cruise

To view this discussion on the web visit https://groups.google.com/d/msgid/flatbuffers/CABsbf%3DErhFoH0YyQfKWSu6%2B0i%2BfyGPg7ZS86MsnPU9Nwe8rV3g%40mail.gmail.com.

[Austin Schuh]

That sounds about right.  The rules assume that it is an external repo.

FYI, and I don't know when I'll get to this, I'd like to revamp the rules to be full bazel rules rather than a set of genrules and macros like they are today.  I would propose that they follow the pattern used by the protobuf rules, and be aspect based.  I'd appreciate any feedback on level of impact and how much to worry about supporting a migration path as opposed to doing a single replacement.  I could also envision building a second set of rules in parallel in a different .bzl file and letting the user select which one they want.

Austin

[Sean McLaughlin]

That sounds like a great idea - maybe initially call the rule something other than flatbuffer_cc_library, and keep the old rule, then eventually make a forwarding wrapper and eliminate the old rule file?

Sean

Sean

To view this discussion on the web visit https://groups.google.com/d/msgid/flatbuffers/CABsbf%3DEHcOuQ-%2Bh4zhQLDFdCTku6Qx_ueh%2BgWXBLFVT2PQeWUw%40mail.gmail.com.

--

Sean McLaughlin Associate Software Engineer Cruise