-
Notifications
You must be signed in to change notification settings - Fork 57
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
Namespaced includes #626
Namespaced includes #626
Conversation
Tested by including all headers in the namespaced form in consumer code and building with the namespace folder removed from the search path. Also verified that an unmodified Neochat still builds fine after this. |
@KitsuneRal so how should we proceed with this? |
Upon a quick glance, I certainly like this approach over #625. I will take a closer look at it next week. |
Any news on this? |
I tested it out with Quaternion and it actually looks quite good. Can you please resolve the conflicts (I think the only actual one is in |
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.
Ok, I actually have one suggestion, but I'm fine to merge this PR without applying it, and implement that suggestion on my end as a separate PR instead.
The include search path propagated by CMake to consumers is adjusted accordingly, so this remains source-compatible.
For this to work transparently, add the include install location to the search path as well.
Setting QUOTIENT_FORCE_NAMESPACED_INCLUDES before the find_package call will not add the namespace include dir to the search path. This isn't really elegant, but allows both retaining full source compatibility and helps consumers that have clashing include file names.
32180f3
to
69aa818
Compare
This is necessary in order to also allow enforcing namespaced includes in embedded/inline builds of libQuotient and is cleaner to do that way then to manually mess with include search paths just for the tests.
This is the alternative approach to #625, and is source-compatible for CMake consumers.
This still needs to be checked for completeness (ie. are all headers really working in a pure namespaced use now), and needs the opt-out switch in the CMake config files, but it should hopefully be sufficient to decide on which of the approaches to take.