Skip to content

WIP: Add a general mechanism for setting rustflags in Cargo for the current crate only #11046

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

Closed
wants to merge 2 commits into from

Conversation

ridwanabdillahi
Copy link

@ridwanabdillahi ridwanabdillahi commented Sep 2, 2022

What does this PR try to resolve?

This PR implements RFC #3310, adding a general mechanism for setting rustflags that only apply to the root crate.

How should we test and review this PR?

This change contains tests at tests/testsuite/rustflags.rs to ensure the new feature works as expected and that rustflags are only where expected.

Additional information

None.

@rust-highfive
Copy link

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @weihanglo (or someone else) soon.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 2, 2022
…ies to the current crate. Add tests to ensure `--rustflags` options are only set for the current crate and not any dependencies.
@bors
Copy link
Contributor

bors commented Oct 17, 2022

☔ The latest upstream changes (presumably #11243) made this pull request unmergeable. Please resolve the merge conflicts.

@epage
Copy link
Contributor

epage commented Jul 18, 2024

#3310 has been postponed and this PR is a couple years stale. I'm closing this. Once we have a design, work can continue to move forward with a PR, picking p from this whatever is relevant.

@epage epage closed this Jul 18, 2024
bradyjeong pushed a commit to bradyjeong/bevy-gta-clone that referenced this pull request Jul 18, 2025
Oracle identified that the macOS doctest issue is due to dynamic library loading
problems where rustdoc-generated test binaries can't find dylibs at runtime.
This is a known limitation (cargo#11046) particularly complex with bevy_dylib.

Changes:
- Skip doctests on macOS in pre-commit script and CI with clear messaging
- Add references to upstream issue rust-lang/cargo#11046
- Static linking approach failed due to bevy_dylib dependency conflicts
- DYLD_FALLBACK_LIBRARY_PATH approach also failed due to SIP restrictions
- Skipping is the most pragmatic approach for v0.4.0-alpha release

This preserves doctest coverage on Linux/Windows while unblocking the release.
Once upstream fixes are available, we can re-enable macOS doctests.

Amp-Thread: https://ampcode.com/threads/T-3d4d1413-9669-48e0-b7cc-8d5a8f20ee96
Co-authored-by: Amp <amp@ampcode.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants