Skip to content

A word on Arduino/PlatformIO compatibility #328

Closed

Description

@codekrolik2

Hello flatcc team.
First and foremost, let me express my utmost gratitude to all of you for building and maintaining such a great project.
I struggled a lot with Google's official C++ codegen and it just didn't work fully for me. Moreover, it introduced some nonsense related to root objects, which shouldn't be there, but most importantly, it wouldn't serialize and deserialize FlatBuf objects as expected (at least on PlatfromIO/RP2040).

So I was super-happy to find flatcc and migrated immediately. Predictably, the reader worked immediately and out of the box. And as much is denoted in your documentation:

Arduino (at least reading buffers)

Yesterday night, however, I stumbled upon the following parts of the docs:

Building a Buffer - Note that the runtime library is required for building buffers, but not for reading them.
Generated Files - The reader does no rely on any library but all other generated files rely on the libflatccrt.a runtime library.
Trouble Shooting - Make sure to link with libflatccrt (rt for runtime) and not libflatcc (the schema compiler), otherwise the builder will not be available.

And only later I found the following information in a rather unlikely section:

Unix Files - In addition the runtime library source files may be used instead of libflatccrt.a

Significantly, before finding that last bit of information, I sort of "rediscovered" the same approach by trial and error and ended up doing just that to add builder support to my PlatformIO project, which so far worked flawlessly and without a single issue.
Given that experience, I'd like to provide a bit of feedback, all of which is IMO.

  1. Messing with binaries at the age of "everything is code" doesn't look great.
  2. While your docs contain a phrase (very hard to find) that the binary lib can be replaced by the code itself, but (IMO) that's worth mentioning whenever binary lib is mentioned.
  3. Ideally, the generated code shold be self-contained and portable. In an ideal world I'd like to just add the generated files to the project, and not think of anything else, i.e. the generated files themselves would contain all the needed code (like in Java version of FlatBuf). That would make the setup super simple and migrating to new versions a bliss. I understand it's much easier said than done, but that comes directly from comparing my Java and C experience (in my case the same FlatBuf schema is shared between the two).

And lastly, since builder worked for me on Arduino, the following line in your docs can be updated:

Arduino (reading buffers; builder - use library source files instead of libflatccrt.a)

Here's my proof-commit: flower-org/phraser@2ba30cb
Apologies for the emotional comment there.

And huge thanks to all the flatcc team again, you're doing an amazing job!

Activity

  1. codekrolik2 commented on Mar 27, 2025

    @codekrolik2
    Author

    Clarification: Java is actually using a binary library, too
    implementation 'com.google.flatbuffers:flatbuffers-java:24.3.25'
    but since it's being auto-linked via single line in Maven/Gradle config, it still counts like everything is code, I guess.
    At least the dev experience is seamless and cross-platform.
    I suppose what I meant was that it would be great to achieve the same ease of use and portability across platforms with flatcc.

  2. locked and limited conversation to collaborators on Mar 28, 2025
  3. converted this issue into a discussion #329 on Mar 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions