Karim/exclude non yoga search paths #1779
Assignees
DaddyFrosty
Clear assignees
DaddyFrosty
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: DaddyFrosty/yoga#1779
Reference in New Issue
Block a user
No description provided.
Delete Branch "karim-alweheshy/karim/exclude_non_yoga_search_paths"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
in rules_swift_package_manager this is necessary to exclude these from search path for public headers that will fail to compile eventually
The latest updates on your projects. Learn more about Vercel for Git ↗︎
Hi @karim-alweheshy!
Thank you for your pull request and welcome to our community.
Action Required
In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.
Process
In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.
Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with
CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!
Could you help provide a bit more context? What error are you seeing?
We have a modulemap for generated umbrella header for Swift usage with the list of public header: https://github.com/facebook/yoga/blob/main/yoga/module.modulemap Wonder if
rules_swift_package_managermight not be picking this up?includes within the target shouldn't ever reference anything outside the
yogadirectory then.Because the public headers search path is set to be on the whole repo, rules_swift_package_manager compiles all public headers from all folders. This compilation fails because imported symbols in these headers are not part of the source.
Excluding the other folders enables rules_swift_package_manager to use the public header only in the
yogafolder and not the restDescribing the set of public headers, for the purpose of creating an umbrella header, is what the modulemap is for, at least when consuming as a Clang module. Or is
rules_swift_package_managercombining headers for some non Clang module purpose? Having a copy of the error would be helpful here.Getting the SwiftPM package to work with Bazel seems like good goal, but this behavior seems funky compared to what SwiftPM itself does/expects. Trying to understand more, to know if maybe this is a bug with
rules_swift_package_managerthat should be reported.There is a difference between how rules_spm work vs SPM itself
I want to double click on this issue specifically, do you agree that the public headers search path for the
coretarget should exclude the mentioned folders?Sorry for the long delay in response!
It's unfortunate that
rules_spmis not respecting modulemaps. I'm a bit surprised there isn't a way to tell it to. I would definitely recommend creating an issue for them, if there really isn't a way to even explicitly tell it to use Yoga's modulemap.We can add workarounds to Yoga for this, so long as we have a way to check that they aren't broken in the future. E.g. if we had a CI rule that could check that things worked, I would feel a lot better about this. One-off changes which may break in the future with unrelated changes, I have been more reluctant to add though.
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.