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

Rustpkg and rustc should use RUST_PATH env var to locate packages #5682

Closed
graydon opened this issue Apr 2, 2013 · 1 comment
Closed

Rustpkg and rustc should use RUST_PATH env var to locate packages #5682

graydon opened this issue Apr 2, 2013 · 1 comment
Labels
A-driver Area: rustc_driver that ties everything together into the `rustc` compiler A-linkage Area: linking into static, shared libraries and binaries C-enhancement Category: An issue proposing an enhancement or a PR with one. E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.
Milestone
0.7

Comments

@graydon
Copy link
Contributor

graydon commented Apr 2, 2013

Sub-bug of #5677

We want to support multiple overlaid stores of libraries and workspaces. Rustpkg should follow a similar strategy to Go here, wherein there's an environment variable -- say $RUST_PATH -- that is a colon (or semi on windows) separated list of "directories in which to resolve pkgids", and the first existing entry in the search path is the directory in which new packages are fetched and installed by default. Target libs need to be put in an arch-specific subdir.

At the end of the $RUST_PATH search (and therefore also the default if users don't define a $RUST_PATH) we should also include some implicit search entries:

  • Any existing dir named .rust in $CWD and every parent of $CWD up to the filesystem root
  • A dir named .rust in the user's homedir, if it exists

The rustc driver should also understand how to search these paths for libraries.

Note that while it is desirable for rustpkg to be "purely functional" and thereby automatically segregate separate builds of the same artifact by storing built artifacts under different version-prefixed or input-hash-prefixed directories, in practice there will always be cases of missing or uncaptured dependencies (environment-sensitivity is very hard to rule out) and providing "different builds in different locations under the user's control" is a necessary mechanism for working around these cases.
@ghost ghost assigned catamorphism Apr 2, 2013
@graydon graydon mentioned this issue Apr 3, 2013
Closed
@catamorphism catamorphism mentioned this issue May 22, 2013
Closed
catamorphism added a commit to catamorphism/rust that referenced this issue May 29, 2013
@catamorphism
rustc/rusti/rustpkg: Infer packages from extern mod directives
af6aad6 
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
@catamorphism
rustc/rusti/rustpkg: Infer packages from extern mod directives
ed3e7a1 
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
@catamorphism
rustc/rusti/rustpkg: Infer packages from extern mod directives
c120464 
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.
@graydon graydon mentioned this issue Jun 6, 2013
Closed
catamorphism added a commit to catamorphism/rust that referenced this issue Jun 12, 2013
@catamorphism
rustc/rusti/rustpkg: Infer packages from extern mod directives
85720c6 
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.
This was referenced Jun 18, 2013
Closed
Closed
catamorphism added a commit to catamorphism/rust that referenced this issue Jun 26, 2013
@catamorphism
rustpkg: Implement RUST_PATH
211d70e 
Unfortunately, the main test for this is ignored due to rust-lang#7071.

Closes rust-lang#5682
This was referenced Jun 26, 2013
Closed
Closed
@catamorphism
Copy link
Contributor

#7397 fixes this, except for the part about the driver knowing about RUST_PATH, which I opened #7398 for. (I guess it's just a matter of moving the code added in #7397 out of rustpkg and into rustc so both can call it.)

bors added a commit that referenced this issue Jun 28, 2013
@bors
auto merge of #7397 : catamorphism/rust/rustpkg_path, r=catamorphism
887ae82 
r? @brson Unfortunately, the main test for this is ignored due to #7071.

Closes #5682
flip1995 pushed a commit to flip1995/rust that referenced this issue Aug 11, 2020
@bors
Auto merge of rust-lang#5889 - ebroto:5886_or_fun_call_const_0_args, …
1683189 
…r=Manishearth

Avoid or_fun_call for const_fn with no args

Based on rust-lang#5682 by @lzutao

This avoids a subset of false positives, specifically those related to `const fn`s that take no arguments.
For the rest, a much more involved fix would be needed, see rust-lang/rust-clippy#5682 (comment).

So this does *not* solve rust-lang#5658

changelog: Avoid triggering [`or_fun_call`] with `const fn`s that take no arguments.

Fixes rust-lang#5886
This was referenced Oct 22, 2022
Open
Open
Open
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-driver Area: rustc_driver that ties everything together into the `rustc` compiler A-linkage Area: linking into static, shared libraries and binaries C-enhancement Category: An issue proposing an enhancement or a PR with one. E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.
Projects
None yet
Milestone
0.7
Development

Successfully merging a pull request may close this issue.

rustpkg: Implement RUST_PATH catamorphism/rust
2 participants
@graydon @catamorphism