Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Style: Harmonize header includes in platform ports #75932
Style: Harmonize header includes in platform ports #75932
Changes from all commits
9e4315b
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't look like paths in other places have to be relative. E.g.
platform/android/api/jni_singleton.h
includingjni_utils.h
.Is there some conflict that prevents resolution?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically both
#platform/android
and the current folder are in the include path, so both work indeed.I've opted for using relative paths for the "local" includes, though I seem to have missed some. Maybe we could remove
#platform/<name>/
from the include path and force using paths relative to the current file?We can alternatively standardize on keeping all paths relative to
#platform/android
as "root" and not use file-related paths at all. I guess that's what my "rule" formulates:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have to admit, that while in spirit the rule is neat, looking at the includes in a random file leaves me puzzled regarding where it's coming from. IDE will resolve it for me anyway, but from the code alone it's currently unclear. And it seems hard to enforce, so going forward you can still get into situations where the included file is not where you expect it to be.
Relative paths are clear, but we tend to avoid them in other places, using project-based paths instead, except for the header definition. Plus, they can quickly become ugly if you have more than a couple levels of hierarchy.
Can we somehow enforce a rule where only
#platform/<name>/
is in the include path, but not other subfolders of a platform (or a module), except for the header file of the same name, if it's cpp?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So yeah going by my initial suggestion, we should probably make all platform/module specific includes relative to the root of their component, and not relative (so all
#platform/<name>/export/
includes would be#include "export/export_plugin.h"
etc.).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I rebased the PR and did the changes we discussed, so the include for e.g.
platform/android/export/export_plugin.h
inplatform/android/export/export.h
is done withexport/export_plugin.h
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this didn't work in the end, because the
api
andexport
folders are special and compiled on all platforms for editor builds. We don't add all platform folders to the include path, so for theapi/*.cpp
andexport/*.cpp
to compile properly, they still need to use relative include paths.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, shame. Well, at least most of the codebase is consistent after these changes. Platforms can be an exception