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

Don't distribute stage1 artifacts #14662

Closed
alexcrichton opened this issue Jun 5, 2014 · 12 comments
Closed

Don't distribute stage1 artifacts #14662

alexcrichton opened this issue Jun 5, 2014 · 12 comments

Comments

@alexcrichton
Copy link
Member

For what I mean by "stage1 artifact", see this comment. The gist of it is that we don't need to distribute things built by the stage1 compiler, only things built by the stage2 compiler.

The tricky part will be figuring out where the host stage2 artifacts go. We could place them in $prefix/lib, but there's a danger of pollution. We could also only place them in $prefix/lib/rustlib/$host/lib, but then there's a danger of the rustc executable not being able to load these libraries seamlessly via rpath.

Solving this should deal with #13421, #11195, and #13733
@alexcrichton
Copy link
Member Author

cc #14650

@alexcrichton
Copy link
Member Author

This will also cut down our distribution size by 60MB

@ghost
Copy link

ghost commented Jun 5, 2014

The FHS says:

Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory.

Also observed by gcc, clang, ghc, mono, ocaml, and probably everyone else.

Another way would be to rename the base libraries to libfoo-stageN-... and shovel everything in $prefix/lib.

@alexcrichton
Copy link
Member Author

cc @brson, maybe a good thing to tackle when dealing with the rust/cargo combined installer as well.

@jgallagher jgallagher mentioned this issue Sep 30, 2014
Closed
@alexcrichton
Copy link
Member Author

cc #16029, this would fix that issue as well.

@pnkfelix
Copy link
Member

Cc me

@oblitum
Copy link

oblitum commented Oct 8, 2014

cc #17289, also to be fixed by this.

@brson
Copy link
Contributor

brson commented Oct 17, 2014

@alexcrichton Putting them in $prefix/lib doesn't seem worse than the situation now, where we are already using that directory. The only concern I see there is if we were to appropriate rustlib as a sort of GAC that cargo also uses to install libraries, in which case we probably would not want to just throw them into $prefix/lib, but split the rust host libs across $prefix/lib and $prefix/lib/rustlib.

FWIW, I expect this to be solved as part of #11145, but restructuring the bootstrap seems pretty far out of scope at the moment. @alexcrichton are you thinking that we would sort of reorganize the artifacts on installation, but not for the bootstrap?

@alexcrichton
Copy link
Member Author

Yeah I do think that #11145 would solve this if we tackled it. I suppose my worry now about $prefix/lib is that lots of libs are installed there, and if we added a usual -L to it we may pick up some extra ones unintentionally.

I suppose we could reorganize for installation but not for bootstrap, but I do agree that it would be a little confusing. If we were to do this near-term, I would propose something like:

  1. Replace all stage1 artifacts with stage2 artifacts.
  2. Remove all stage2 artifacts in $prefix/lib from $prefix/lib/rustlib/$target/lib.
  3. Implicitly add $prefix/lib to the set of -L paths.

This would allow us to deduplicate our distribution strategy (only distributing one set of artifacts) and would be roughly equivalent to what the bootstrap process looks like today, just not exactly so.

@steveklabnik
Copy link
Member

Traige: as far as I know, this is still an issue today.

@oblitum
Copy link

oblitum commented Feb 2, 2016

cc #16029

@alexcrichton
Copy link
Member Author

We've changed enough about our distribution that I don't believe this is relevant any more, so closing.

bors added a commit to rust-lang-ci/rust that referenced this issue Jun 5, 2023
@bors
Auto merge of rust-lang#14662 - Ddystopia:open_locally_built_document…
c9b4116 
…atin_instead_of_docs_dot_rs, r=Ddystopia

 Provide links to locally built documentation for `experimental/externalDocs`

This pull request addresses issue rust-lang#12867, which requested the ability to provide links to locally built documentation when using the "Open docs for symbol" feature. Previously, rust-analyzer always used docs.rs for this purpose. With these changes, the feature will provide both web (docs.rs) and local documentation links without verifying their existence.

Changes in this PR:

   - Added support for local documentation links alongside web documentation links.
   - Added `target_dir` path argument for external_docs and other related methods.
   - Added `sysroot` argument for external_docs.
   - Added `target_directory` path to `CargoWorkspace`.

API Changes:

   - Added an experimental client capability `{ "localDocs": boolean }`. If this capability is set, the `Open External Documentation` request returned from the server will include both web and local documentation links in the `ExternalDocsResponse` object.

Here's the `ExternalDocsResponse` interface:

```typescript
interface ExternalDocsResponse {
    web?: string;
    local?: string;
}
```

By providing links to both web-based and locally built documentation, this update improves the developer experience for those using different versions of crates, git dependencies, or local crates not available on docs.rs. Rust-analyzer will now provide both web (docs.rs) and local documentation links, leaving it to the client to open the desired link. Please note that this update does not perform any checks to ensure the validity of the provided links.
bors added a commit to rust-lang-ci/rust that referenced this issue Nov 13, 2023
@bors
Auto merge of rust-lang#15728 - EliasHolzmann:feature/local_documenta…
8a23314 
…tion_vscode, r=Veykril

feat: vscode: Support opening local documentation if available

This PR implements the VS code support for opening local documentation (server side support was already implemented in rust-lang#14662).

[local_docs.webm](https://github.com/rust-lang/rust-analyzer/assets/9659253/715b84dd-4f14-4ba0-a904-749b847eb3d5)

Displaying local instead of web docs can have many benefits:
- the web version may have different features enabled than locally selected
- the standard library may be a different version than is available online
- the user may not be online and therefore cannot access the web documentation
- the documentation may not be available online at all, for example because it is for a new feature in a library the user is currently developing

If the documentation is not available locally, the extension still falls back to the web version.

Closes rust-lang#12867.

-----

If my implementation isn't really idiomatic TypeScript: Sorry, I'm not much of a TypeScript developer. I am open to feedback, however.
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

No branches or pull requests
5 participants
@steveklabnik @alexcrichton @brson @pnkfelix @oblitum