Skip to content
This repository has been archived by the owner on Nov 5, 2022. It is now read-only.

Cargo pre-planning: project knowledge #15

Open
nrc opened this issue Nov 8, 2018 · 3 comments
Open

Cargo pre-planning: project knowledge #15

nrc opened this issue Nov 8, 2018 · 3 comments

Comments

@nrc
Copy link
Member

nrc commented Nov 8, 2018

  • std-aware/Xargo
  • sysroot/extern crate stuff

cc @japaric, @ehuss , @alexcrichton , @joshtriplett

@nrc nrc mentioned this issue Nov 8, 2018
5 tasks
@nrc
Copy link
Member Author

nrc commented Nov 20, 2018

ping @japaric, @ehuss , @alexcrichton , @joshtriplett

Could start to develop the design space/layout the options and pros/cons here please?

@alexcrichton
Copy link
Member

Sorry I haven't had a lot of time to dig into this, I was planning on revisiting/posting to this after the 2018 edition is out

@alexcrichton
Copy link
Member

Ok I've got some time, so here's some thoughts!

I think the biggest impact thing we can do here is to basically "fix" Cargo's handling of the standard library. This includes things like:

  • I'm compiling for MinGW on Linux, I have to remember rustup target add
  • I'm compiling for WebAssembly, but I'd like to test out the upcoming atomics feature, I have to remember to use xargo or cargo-xbuild
  • I'm compiling a target where there are no official binaries, I have to remember to use xargo or cargo-xbuild
  • I'm experimenting with various options like instrumentation, miri, profiling, etc, and I need to remember to recompile the standard libary with various flags
  • I'd like to express some degree of configuration about the standard library. For example I don't want backtraces enabled or maybe I want panics to immediately abort with no diagnostics for code size. The list of possibilities here is quite long!

I'm sure there's other entries for this list as well. I think that we can definitely collect enough use cases to make a compelling argument that this should be prioritized. The main con and difficulty will be designing this in a way we're all comfortable stabilizing. There's been some great groundwork historically and we're almost there, I think we just need to give it another final push to get over the design hump before we can make progress.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants