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.

Sign up for GitHub

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

Jump to bottom

Add --extern foo=path command line flag #14469

Closed
brson opened this issue May 27, 2014 · 2 comments · Fixed by #15319
Closed

Add --extern foo=path command line flag #14469

brson opened this issue May 27, 2014 · 2 comments · Fixed by #15319

Comments

@brson
Copy link
Contributor

brson commented May 27, 2014

cc #14468

Add a command line flag to let tools like cargo specify exactly which library to use for an extern crate statement.

It looks like --extern foo=path, where "foo" is the name of a crate, and path is the path of a rust library, without the extension (so it will look for both .rlib and .dylib).
@brson brson added the A-pkg label May 27, 2014
@alexcrichton alexcrichton mentioned this issue Jun 6, 2014
Merged
@alexcrichton alexcrichton mentioned this issue Jul 2, 2014
Merged
bors added a commit that referenced this issue Jul 5, 2014
@bors
auto merge of #15319 : alexcrichton/rust/no-crate-id, r=brson
c3ef04b 
This is an implementation of [RFC 35](https://github.com/rust-lang/rfcs/blob/master/active/0035-remove-crate-id.md).

The summary for this PR is the same as that of the RFC, with one addendum:


* Removes the `#[crate_id]` attribute and knowledge of versions from rustc.
* Added a `#[crate_name]` attribute similar to the old `#[crate_id]` attribute
* Output filenames no longer have versions or hashes
* Symbols no longer have versions (they still have hashes)
* A new flag, `--extern`, is used to override searching for external crates
* A new flag, `-C metadata=foo`, used when hashing symbols
* [added] An old flag, `--crate-name`, was re purposed to specify the crate name from the command line.

I tried to maintain backwards compatibility wherever possible (with warnings being printed). If I missed anywhere, however, please let me know!

[breaking-change]

Closes #14468
Closes #14469
Closes #14470
Closes #14471
@tomjakubowski
Copy link
Contributor

Does it make sense for the rustdoc command to take this flag as well?

@alexcrichton
Copy link
Member

Yes, in general rustdoc should mirror rustc wherever necessary. Eventually cargo will require this flag for rustdoc anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Remove #[crate_id] alexcrichton/rust
3 participants
@alexcrichton @brson @tomjakubowski