Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

This pull request is stale because it has been open 6 months with no activity. Please comment or label not-stale, or this will be closed in 14 days.

Hello
What can I do to "unstale" this branch?
I believe there needs to have an "approving review" but I'm not sure how to get this

@obones the branch is stale because it hasn't had any commits for the past few months. Have you signed the CLA ?

@obones the branch is stale because it hasn't had any commits for the past few months. Have you signed the CLA ?

I believe I did, at least that's what I inferred from the cla/google check being successful.

I have created a PR to your branch to update the version in the library.json with the release. I think its just a matter of waiting for a maintainer

Thanks, I have merged it and rebased my branch on top of master.
Hopefully someone will notice this PR.

So it seems this never got merged? Too bad...

So it seems this never got merged? Too bad...

Well, I just rebased it once more, for any one to look at.
I sincerely have no idea why "buildifier" is not happy

Any chances to get this merged for PIO support?

This pull request is stale because it has been open 6 months with no activity. Please comment or label not-stale, or this will be closed in 14 days.

I have just rebased this PR to the master branch, I hope this will eventually be merged

@obones would you mind rebasing once more and updating the version to the current latest?

it also may help to document somewhere that library.json is for - maybe even just in an _comment field of the file itself.

This has just been done, let me know if anything else is required

I want to try and get a basic PlatformIO example project going where I can include this and test it out -- The only blocker I see is if we should actually build the flatbuffers static library as part of the project. Happily welcoming any feedback on the necessity of this from actual PlatformIO users -- @obones @srgg @sylque @FlavioZanoni

The only blocker I see is if we should actually build the flatbuffers static library as part of the project

I'm using flatbuffers in PlatformIO as a header-only library. All what's needed is the content of https://github.com/google/flatbuffers/tree/master/include/flatbuffers (only .h files).

doing a bit more review of this, it seems this library.json adds several restrictions that don't seem to make sense -- only restricting to espressif32 and arduino / espidf doesn't really align with the project.

I think it would be good to evaluate making this file much more generic, and compiling the static library. I will continue to try and get an environment set up to evaluate this PR though!

The only blocker I see is if we should actually build the flatbuffers static library as part of the project.

I'm doing the same as @sylque in my esp-idf and PlatformIO projects, using only the headers available in /include/flatbuffers,

The way I see it, it's best to only include the header files, license, README.md, and the library.json in the exports, like ArduinoJson or AsyncTCP.

also

only restricting to espressif32 and arduino / espidf doesn't really align with the project.

ArduinoJson just puts an "*" in the platforms

"platforms": "*",

doing a bit more review of this, it seems this library.json adds several restrictions that don't seem to make sense -- only restricting to espressif32 and arduino / espidf doesn't really align with the project.

I think it would be good to evaluate making this file much more generic, and compiling the static library. I will continue to try and get an environment set up to evaluate this PR though!

ArduinoJson just puts an "*" in the platforms

"platforms": "*",

Well, I restricted it because that's the only ones I could test with, and the ones that I believe are the most used, but that can be changed, it's just that I can't vouch for compatibility

so flatbuffers must be used as header only.

Yes, that is expected because none of the other sources are required. The whole point of this definition file is to allow the consumption/creation of predefined buffers, not compile/generate files on the target platforms.
The process is as is:

1. Use a computer running Windows/Linux/MacOS to edit the schema
2. On that same computer, call flatc to generate the language specific code (C/C++ in most cases)
3. Use the generated files within a PlatfomIO project, targeting an embedded platform

This way, nothing but the flatbuffers/flatbuffers.h is actually required as it's the one included by the generated files.

I will do some digging, but I don't believe flatbuffers.h is strictly intended to function as a header only library (even though I'm using it very much the same way in my own applications) -- util.h (maybe others?) do have some functions defined in cpp files, though I'm uncertain if that header is included through flatbuffers.h. As this is set up now, though, util.h is reachable from this library.json.

I want to be cognizant of pushing something to this upstream that has known broken issues, which is why I'm chasing this goose :)

Had some more chats and thoughts about this and its probably not worth the investment to prevent access to util.h and idl.h functions that require compilation. I do still think we should not restrict the platforms and frameworks though, as @FlavioZanoni suggested

I just changed platforms and frameworks to * so that it will be usable with anything supported by PlatformIO, which should work just fine considering that it's pure C++ with no exotic dependencies.

Neat -- this looks good. I still want to make an attempt to test it myself, will try to do so this afternoon.

neat! can be manually imported but then shows up and can be found by the compiler.