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
Place the public API in a special place with a canonical way of accessing them #322
Place the public API in a special place with a canonical way of accessing them #322
Changes from 4 commits
554ff00
c8ae6be
6bdc44f
1c60c36
2e7407c
c861cc5
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.
Why is
umd/device
not part of the build include path?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.
Because we haven't discussed what internal access should look like. This PR was demonstrating external access and putting all the public headers in a segregated place to distinguish external vs internal. That aspect is more straightforward / objective.
Internal access is more subjective.
On the one hand, accessing the same way as an external consumer makes it obvious when we're using a public API -- does that matter? For some projects maybe that's useful information and for others it's inconsequential.
It also means that moving a file from internal to external doesn't require changing the includes. In a project highly in flux, perhaps that's a useful convenience. But if structing include ordering to indicate proximity, then it'll need to be updated anyway. And in a more well established project hoisting a module externally is very very rare in the grand scheme of things.
On the other hand, accessing like any other internal header separates on a different concern: I'm conveying that this is a header within this project, but I'm not affected nor do I care whether said header is ALSO available externally or not. Not my concern.
I believe @blozano-tt prefers the former. I prefer the latter. But ultimately neither of us own UMD, so it's you and @broskoTT who should make a call re: what you prefer internal for your project. I can help guide on the CMake change for whichever you prefer.