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

Add a stable version of x.py #76380

Closed
jyn514 opened this issue Sep 5, 2020 · 5 comments
Closed

Add a stable version of x.py #76380

jyn514 opened this issue Sep 5, 2020 · 5 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

Comments

@jyn514
Copy link
Member

jyn514 commented Sep 5, 2020 •
edited
Loading

This came up in #76165 in response to the changes from #73964: currently the way to adapt to changes in x.py is 'learn about them because it broke something and change your workflow'. This is not ideal, especially for automated scripts. It would be great to have a separate, stable interface that doesn't change regardless of any changes to contributor defaults.

I imagine the defaults looking mostly, but not exactly, like the defaults prior to #73964:

  • the default stage will go back to 2 for all subcommands
  • src/rustc will be on by default
  • debuginfo = 1 by default when debug = true will not be reverted - if you have strong opinions about debuginfo I expect you already have debug = false for a release build.

The setup I imagine is two different scripts that work on the same underlying codebase: x.py and bootstrap.py, where bootstrap.py is the stable version. Both will be 'facades' around the current src/bootstrap/bootstrap.py, and the logic of choosing defaults will still live in bootstrap.py and the rustbuild crate.
@jyn514 jyn514 added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Sep 5, 2020
@jyn514
Copy link
Member Author

jyn514 commented Sep 5, 2020

cc @infinity0 - would this address your concerns about the changes?

@infinity0
Copy link
Contributor

@jyn514 it sounds fine from my side, but others might find it confusing to have two top-level scripts with the same subcommand names and mostly-the-same CLI options. I'd be happy to call src/bootstrap/bootstrap.py directly - I'm doing that already anyway since Debian is encouraging us to use Python 3, and ./x.py hardcodes Python 2.

I also predict it would be more long-term work to wrap a stable API around unstable logic that selects convenient defaults, than wrapping unstable logic around a stable API, but perhaps you meant something slightly different from how I'm interpreting what you wrote.

@jyn514
Copy link
Member Author

jyn514 commented Sep 5, 2020 •
edited
Loading

Ooh, calling src/bootstrap/bootstrap.py directly sounds like a great idea, let's do that.

I also predict it would be more long-term work to wrap a stable API around unstable logic that selects convenient defaults, than wrapping unstable logic around a stable API, but perhaps you meant something slightly different from how I'm interpreting what you wrote.

I'm a little undecided myself - my original idea was to have a wrapper that adds --stage 2 on top and such, but that means that it has to reimplement its own parsing to avoid conflicting with any flags the user passes. So the idea I had was to have the bootstrap binary know about both defaults, the way rustc knows about both 2015 and 2018 edition. That way there can't be conflicts because the parsing is in sync.

@infinity0
Copy link
Contributor

has to reimplement its own parsing to avoid conflicting with any flags the user passes. So the idea I had was to have the bootstrap binary know about both defaults

Ah right, yes for some reason I thought bootstrap.py already did some parsing, but it looks like that's not the case. What you're saying makes sense now.

@jyn514
Copy link
Member Author

jyn514 commented Sep 11, 2020

@infinity0 I talked about this with @Mark-Simulacrum and we decided that maintaining a stable version of x.py in perpetuity would be too high of a maintenance burden; for instance, it wouldn't have allowed the changes in #76415.

As an alternative, I opened several other issues that should help with your use case:

I'd love to hear your opinions on those! But I don't think a stable x.py is ever going to be implemented, so closing this.

@jyn514 jyn514 closed this as completed Sep 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@infinity0 @jyn514