Rustpkg should extract dependencies from extern mod statements.
#5681
Labels
E-hard
Call for participation: Hard difficulty. Experience needed to fix: A lot.
Milestone
Comments
ghost
assigned 
|
I opened a separate bug, #6407, for the second bullet point. I'm going to implement this issue first. |
|
Er, "this issue" as in inference; then I'll expand what's allowed in |
|
The first part of this is done, except for cleaning up tidy errors and figuring out how to work around a borrow check issue that I'm currently handling with a copy. I might just submit a pull request with the latter issue unfixed and request advice. |
catamorphism
added a commit
to catamorphism/rust
that referenced
this issue
May 29, 2013
This commit won't be quite as useful until I implement RUST_PATH and until we change `extern mod` to take a general string instead of an identifier (rust-lang#5682 and rust-lang#6407). With that said, now if you're using rustpkg and a program contains: extern mod foo; rustpkg will attempt to search for `foo`, so that you don't have to provide a -L directory explicitly. In addition, rustpkg will actually try to build and install `foo`, unless it's already installed (specifically, I tested that `extern mod extra;` would not cause it to try to find source for `extra` and compile it again). This is as per rust-lang#5681. Incidentally, I changed some driver code to infer the link name from the crate link_meta attributes. If that change isn't ok, say something.
catamorphism
added a commit
to catamorphism/rust
that referenced
this issue
May 30, 2013
This commit won't be quite as useful until I implement RUST_PATH and until we change `extern mod` to take a general string instead of an identifier (rust-lang#5682 and rust-lang#6407). With that said, now if you're using rustpkg and a program contains: extern mod foo; rustpkg will attempt to search for `foo`, so that you don't have to provide a -L directory explicitly. In addition, rustpkg will actually try to build and install `foo`, unless it's already installed (specifically, I tested that `extern mod extra;` would not cause it to try to find source for `extra` and compile it again). This is as per rust-lang#5681. Incidentally, I changed some driver code to infer the link name from the crate link_meta attributes. If that change isn't ok, say something. Also, I changed the addl_lib_search_paths field in the session options to be an @mut ~[Path] so that it can be modified after expansion but before later phases.
catamorphism
added a commit
to catamorphism/rust
that referenced
this issue
Jun 2, 2013
This commit won't be quite as useful until I implement RUST_PATH and until we change `extern mod` to take a general string instead of an identifier (rust-lang#5682 and rust-lang#6407). With that said, now if you're using rustpkg and a program contains: extern mod foo; rustpkg will attempt to search for `foo`, so that you don't have to provide a -L directory explicitly. In addition, rustpkg will actually try to build and install `foo`, unless it's already installed (specifically, I tested that `extern mod extra;` would not cause it to try to find source for `extra` and compile it again). This is as per rust-lang#5681. Incidentally, I changed some driver code to infer the link name from the crate link_meta attributes. If that change isn't ok, say something. Also, I changed the addl_lib_search_paths field in the session options to be an @mut ~[Path] so that it can be modified after expansion but before later phases.
catamorphism
added a commit
to catamorphism/rust
that referenced
this issue
Jun 12, 2013
This commit won't be quite as useful until I implement RUST_PATH and until we change `extern mod` to take a general string instead of an identifier (rust-lang#5682 and rust-lang#6407). With that said, now if you're using rustpkg and a program contains: extern mod foo; rustpkg will attempt to search for `foo`, so that you don't have to provide a -L directory explicitly. In addition, rustpkg will actually try to build and install `foo`, unless it's already installed (specifically, I tested that `extern mod extra;` would not cause it to try to find source for `extra` and compile it again). This is as per rust-lang#5681. Incidentally, I changed some driver code to infer the link name from the crate link_meta attributes. If that change isn't ok, say something.
|
Closing -- #6407 captures what's left of this. |
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Jun 5, 2020
match_wildcard_for_single_variants: remove empty line at start of lint example. See https://rust-lang.github.io/rust-clippy/master/index.html#match_wildcard_for_single_variants changelog: none
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Sub-bug of #5677
Rustpkg currently parses
pkg.rsto figure out dependencies between packages. This has to change:pkg.rsfiles. It needs to find dependencies by inference by default. This means reading the source files and looking forextern modstatements (post-syntax-expansion and post-cfg-filtering).extern modstatements should be pkgids, which should be enough to find and install a package through a variety of mechanisms (RUST_PATH search order, falling back to local binary package management and/or fetching source from a URL)The text was updated successfully, but these errors were encountered: