Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flatbuffer header files should not have a flatbuffers include prefix #8084

Closed
rweickelt opened this issue Sep 1, 2023 · 2 comments
Closed
Labels

Comments

@rweickelt
Copy link

The generated flatbuffer header expects the flatbuffer headers to be located in a flatbuffers folder:

#include "flatbuffers/flatbuffers.h"

This is problematic when cross-building for embedded targets using the host installation of flatbuffers. The includes are located under /usr/include/flatbuffers in most Linux distributions. The generated flatbuffer header and also flatbuffers/flatbuffers.h require the compiler include path set to /usr/include which takes precedence over default compiler include paths. Various problems arise, like the compiler finding the wrong standard lib and so on.

There are ways to work around that problem like creating symlinks to /usr/include/flatbuffers somewhere in the project or build directory so that the compiler include path can be set to the folder containing the symlink. But that is neither portable nor maintainable.

I would prefer the flatbuffer headers if the flatbuffer did not require a flatbuffers include prefix at all or at least, if it would be configurable in the generated header.

Copy link

github-actions bot commented Mar 1, 2024

This issue 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.

@github-actions github-actions bot added the stale label Mar 1, 2024
Copy link

This issue was automatically closed due to no activity for 6 months plus the 14 day notice period.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant