Skip to content

Possibly support -p for standard library dependencies. #26

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.

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

Open
ehuss opened this issue Sep 6, 2019 · 2 comments
Open

Possibly support -p for standard library dependencies. #26

ehuss opened this issue Sep 6, 2019 · 2 comments
Labels
implementation Implementation exploration and tracking issues

Comments

@ehuss
Copy link
Contributor

ehuss commented Sep 6, 2019

Commands like cargo build can take the -p flag to build any dependency. The current implementation does not support doing this for standard library dependencies. Should this be supported?

@ehuss ehuss added the implementation Implementation exploration and tracking issues label Sep 6, 2019
@Ericson2314
Copy link

Yes I think it should; anything to make stdlib deps more normal is good.

@c272
Copy link

c272 commented Feb 21, 2024

One possible implementation of this, which I have been testing as a patch, could work something like this:

  • Both cargo build -p [...] and cargo clean -p [...] support specifying standard library packages when -Zbuild-std is passed.
  • The -Zbuild-std=... flag essentially acts as an extension of -p and vice versa.
    • For example, cargo build -p foo -p core -p std -Zbuild-std would be equivalent to cargo build -p foo -Zbuild-std=core,std.
    • This would help remove ambiguity if a package with the same name existed in both workspaces, as if specified in the -Z argument, there is no doubt which is being targeted.
    • One drawback to this approach is that users specifying a static set of packages in .cargo/config.toml would have to remove these if wishing to build only a subset via. -p.
  • If a -p spec matches a package name present in both the standard library workspace and the user workspace, a warning is presented and only the user package is selected.
    • This allows for the maximum range of selection, with the user able to pick only the user package (-p foo), the user package and the std package (-p foo -Zbuild-std=foo) and only the std package (-Zbuild-std=foo).

With the standard library occupying its own workspace currently, however, this does bring to mind a few implementation snags:

  • When processing -p arguments, they would somehow have to be filtered into those intended for the standard library workspace, and those for the user workspace. This would likely involve creating a standard library resolve prior to compilation.
  • This will add more stdlib-specific processing internally within Cargo.

Thinking further ahead, this could be one possible avenue of stabilising build-std into a standard command line option in place of -Zbuild-std, if there is a replacement for the .cargo/config.toml field in some form. This is obviously a slightly larger scoped discussion, though.

What are people's opinions on this approach? This would allow for user and stdlib packages to appear in the same space to the end user, however I would be interested in any alternative suggestions.

Related: #21

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
implementation Implementation exploration and tracking issues
Projects
None yet
Development

No branches or pull requests

3 participants