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

--keep-prefix broken with includes in separate directories #7486

Closed
akb825 opened this issue Aug 27, 2022 · 9 comments
Closed

--keep-prefix broken with includes in separate directories #7486

akb825 opened this issue Aug 27, 2022 · 9 comments

Comments

@akb825
Copy link
Contributor

akb825 commented Aug 27, 2022

The changes in #7354 introduced a regression where --keep-prefix will only work if the include is in the same directory structure as the .fbs file being compiled. If the include is in a separate directory structure passed with the -I argument, the prefix will be stripped.

For example, if your directory structure is:

<dir>/foo.fbs
<dir>/bar/baz.fbs

and foo.fbs has the following include line:

include "bar/baz.fbs"

the prefix will be preserved. i.e. the generated .cpp file will have the line

#include "bar/baz_generated.h"

However, if your directory structure is:

<dir>/foo.fbs
<other-dir>/bar/baz.fbs

when you call flatc --cpp --keep-prefix -I <other-dir> foo.fbs the prefix is missing. i.e. you end up with:

#include "baz_generated.h"

This regression breaks any projects that depend on external includes or has separate root include directories in a project. As of yet I haven't found any workarounds apart from completely changing the project structure or downgrading to 2.0.6.

@dbaileychess
Copy link
Collaborator

Do you have #7469? This was verified by others.

@akb825
Copy link
Contributor Author

akb825 commented Aug 28, 2022

I'm using the system package provided by Arch Linux, which doesn't have that commit included as it was based off the 2.0.7 release. Recompiling the package with that commit applied fixes the issue.

I'd imagine I'm far from the only one using a system package or sticking to release versions in general. Is this regression disruptive enough for general usage to justify a new patch release in the meantime to avoid others running into the same issue?

@dbaileychess
Copy link
Collaborator

Ack.

Do you know if Arch linux (and others) pick up only "Releases" or any Tag version?

@dbaileychess
Copy link
Collaborator

Will go to 2.0.8 soon. I have one other fix I want in it. Should be today or tomorrow.

@akb825
Copy link
Contributor Author

akb825 commented Aug 29, 2022

In my experience Arch had picked up tags, but Homebrew on Mac has only checked releases, so it varies by distro. With the new release you planned it should be good either way. 👍

@dbaileychess
Copy link
Collaborator

Release 2.0.8 is up for C++ https://github.com/google/flatbuffers/releases/tag/v2.0.8

@musicinmybrain
Copy link
Contributor

Do you know if Arch linux (and others) pick up only "Releases" or any Tag version?

I maintain the flatbuffers package in Fedora Linux and EPEL 9. I get update notifications via the release-monitoring.org project, which is configured to check tags.

@dbaileychess
Copy link
Collaborator

Thanks, good to know.

@akb825
Copy link
Contributor Author

akb825 commented Sep 1, 2022

Thanks!

@akb825 akb825 closed this as completed Sep 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants