Skip to content

Tracking Issue --extern crate modifiers #98405

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
petrochenkov opened this issue Jun 22, 2022 · 2 comments
Open

Tracking Issue --extern crate modifiers #98405

petrochenkov opened this issue Jun 22, 2022 · 2 comments
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC

Comments

@petrochenkov
Copy link
Contributor

petrochenkov commented Jun 22, 2022

This is a tracking issue for command line option syntax currently used by several modifiers affecting behavior of extern crates.
Specific tracking issues for those modifiers:

The currently used syntax is

--extern [MODIFIERS:]NAME[=PATH]

Before stabilization it should likely be harmonized with command line syntax already used for native library modifiers, see item (3) in #93901 (comment).

  • Modifiers can be converted to +/- form
    • priv - +priv or -pub
    • noprelude - -prelude
    • nounused - +used
  • Position of the MODIFIERS component in the option can also be changed.
@petrochenkov petrochenkov added the C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC label Jun 22, 2022
@jsgf
Copy link
Contributor

jsgf commented Jun 25, 2022

Before stabilization it should likely be harmonized with command line syntax already used for native library modifiers, see item (3) in #93901 (comment).
Modifiers can be converted to +/- form

I don't really see the relationship between #[link] and --extern flag:. The latter controls how a Rust dependency is handled/consumed by this particular rustc invocation, whereas the former controls how an external non-Rust dependency is finally linked.

(I also think the whole #[link] mechanism is a bad idea and should be deprecated, not extended. Controlling how things are ultimately linked is the responsibility of the build system, and so the functionality should be moved to Cargo.)

@ehuss
Copy link
Contributor

ehuss commented Jun 25, 2022

I don't think that is referring to #[link], just that it should use the same +/- syntax of the -l flag, like --extern +prev,-prelude:foo=libfoo.rlib or possibly rearranged to --extern foo:+prev,-prelude=libfoo.rlib

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC
Projects
None yet
Development

No branches or pull requests

3 participants