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

C/C++ language standards should be set per-target #1079

Open
Tracked by #924
brentleyjones opened this issue May 21, 2024 · 4 comments · May be fixed by #1217
Open
Tracked by #924

C/C++ language standards should be set per-target #1079

brentleyjones opened this issue May 21, 2024 · 4 comments · May be fixed by #1217
Assignees
Labels
bug Something isn't working

Comments

@brentleyjones
Copy link
Collaborator

We shouldn't recommend that users set workspace-wide --copt/--cxxopt flags. Instead we should set the required flags on the {cc,objc}_library targets. If a target has both C and C++ files, we may need to split the target in two in order to apply the correct flag to each one.

@brentleyjones brentleyjones mentioned this issue Jun 18, 2024
19 tasks
@cgrindel cgrindel added enhancement New feature or request bug Something isn't working and removed enhancement New feature or request labels Jul 7, 2024
@cgrindel cgrindel self-assigned this Jul 14, 2024
@cgrindel
Copy link
Owner

@brentleyjones Do you have an example where a Swift package combines c and c++ in the same target? If so, I will use it as a test case.

@brentleyjones
Copy link
Collaborator Author

I don't know of one in the wild. I'm not even 100% sure SwiftPM allows it (though I expect it does). I know Bazel does, and it leads to issues with copts, so you generally should split them.

@brentleyjones
Copy link
Collaborator Author

@cgrindel
Copy link
Owner

I am going to write the support as if it can be one or the other. If we run into a real-world example that says otherwise, I will adjust the logic accordingly.

cgrindel added a commit that referenced this issue Jul 30, 2024
Refactor the resource bundle code so that the accessor generation is not
buried in a shared function. This is a precursor for implementing #1079.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants