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.

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

test tidy should ignore alternative build dir patterns #84530

Merged
merged 1 commit into from
Apr 29, 2021

Conversation

richkadel
Copy link
Contributor

I need to have multiple build directories, such as build,
build-fuchsia, and build-test. But when I'm uploading a change, I
run ./x.py test tidy, and if I have a build-something directory with
Rust sources, I git a bunch of formatting errors.

rustfmt.toml only ignores the directory named build.

This change extends the patterns to also ignore build-* and *-build.

As a rustc contributor, I not only build the rust compiler to develop
new features, but I also build alternative "distributions" (using
secondary *-config.toml files with different configurations),
including:

  • To occasionally rebuild a version of the compiler that rust-analyzer
    can use to check source (which fixes issues in the VS Code UI, so
    changing and rebuilding the compiler does not break VS Code editing Rust
    code).
  • To build custom distributions for Fuchsia
  • To build test distributions when working on changes to bootstrap
    (e.g., when I recently added rust-demangler to distributions)

I need to have multiple `build` directories, such as `build`,
`build-fuchsia`, and `build-test`. But when I'm uploading a change, I
run `./x.py test tidy`, and if I have a `build-something` directory with
Rust sources, I git a bunch of formatting errors.

`rustfmt.toml` only ignores the directory named `build`.

This change extends the patterns to also ignore `build-*` and `*-build`.

As a rustc contributor, I not only build the rust compiler to develop
new features, but I also build alternative "distributions" (using
secondary `*-config.toml` files with different configurations),
including:

* To occasionally rebuild a version of the compiler that `rust-analyzer`
can use to `check` source (which fixes issues in the VS Code UI, so
changing and rebuilding the compiler does not break VS Code editing Rust
code).
* To build custom distributions for Fuchsia
* To build test distributions when working on changes to `bootstrap`
(e.g., when I recently added `rust-demangler` to distributions)
@rust-highfive
Copy link
Collaborator

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 24, 2021
@jyn514
Copy link
Member

jyn514 commented Apr 25, 2021

@richkadel I'm curious - what's your workflow look like for those different build directories? Are you testing the same changes for multiple targets? Or are you switching between branches and you don't want to lose the build cache? For the second case I'd recommend git worktrees instead: https://rustc-dev-guide.rust-lang.org/building/suggested.html#working-on-multiple-branches-at-the-same-time

@jyn514 jyn514 added the A-contributor-roadblock Area: Makes things more difficult for new contributors to rust itself label Apr 25, 2021
@richkadel
Copy link
Contributor Author

It's the first case. For example, I normally build with debug, targeting only linux, and sometimes with a debug build of LLVM.

But when testing with Fuchsia, I have to use a very specific set of config.toml flags, targets, and install directories, etc. So I have a separate fuchsia-config.toml with those settings, and they build into fuchsia-build. As needed, I can make a rustc source change, rebuild and test with my normal config.toml, and when I'm ready, rebuild the fuchsia version and test in fuchsia.

@richkadel
Copy link
Contributor Author

@Mark-Simulacrum - Any questions or concerns here?

(rust-highfive added you as reviewer. Let me know if you'd like someone else to review instead.)

Thanks!
Rich

@Mark-Simulacrum
Copy link
Member

I usually take several days to get to an initial review - unfortunately accumulated some backlog which I've been processing over the last several days, so hopefully will get to this soon.

@richkadel
Copy link
Contributor Author

No problem and no rush. Thanks for letting me know.

@Mark-Simulacrum
Copy link
Member

@bors r+ rollup

Seems reasonable to me, thanks. Interesting pattern for sure!

@bors
Copy link
Contributor

bors commented Apr 28, 2021

📌 Commit 79020a8 has been approved by Mark-Simulacrum

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 28, 2021
m-ou-se added a commit to m-ou-se/rust that referenced this pull request Apr 28, 2021
…ark-Simulacrum

`test tidy` should ignore alternative `build` dir patterns

I need to have multiple `build` directories, such as `build`,
`build-fuchsia`, and `build-test`. But when I'm uploading a change, I
run `./x.py test tidy`, and if I have a `build-something` directory with
Rust sources, I git a bunch of formatting errors.

`rustfmt.toml` only ignores the directory named `build`.

This change extends the patterns to also ignore `build-*` and `*-build`.

As a rustc contributor, I not only build the rust compiler to develop
new features, but I also build alternative "distributions" (using
secondary `*-config.toml` files with different configurations),
including:

* To occasionally rebuild a version of the compiler that `rust-analyzer`
can use to `check` source (which fixes issues in the VS Code UI, so
changing and rebuilding the compiler does not break VS Code editing Rust
code).
* To build custom distributions for Fuchsia
* To build test distributions when working on changes to `bootstrap`
(e.g., when I recently added `rust-demangler` to distributions)
jackh726 added a commit to jackh726/rust that referenced this pull request Apr 29, 2021
…ark-Simulacrum

`test tidy` should ignore alternative `build` dir patterns

I need to have multiple `build` directories, such as `build`,
`build-fuchsia`, and `build-test`. But when I'm uploading a change, I
run `./x.py test tidy`, and if I have a `build-something` directory with
Rust sources, I git a bunch of formatting errors.

`rustfmt.toml` only ignores the directory named `build`.

This change extends the patterns to also ignore `build-*` and `*-build`.

As a rustc contributor, I not only build the rust compiler to develop
new features, but I also build alternative "distributions" (using
secondary `*-config.toml` files with different configurations),
including:

* To occasionally rebuild a version of the compiler that `rust-analyzer`
can use to `check` source (which fixes issues in the VS Code UI, so
changing and rebuilding the compiler does not break VS Code editing Rust
code).
* To build custom distributions for Fuchsia
* To build test distributions when working on changes to `bootstrap`
(e.g., when I recently added `rust-demangler` to distributions)
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 29, 2021
Rollup of 11 pull requests

Successful merges:

 - rust-lang#84484 (Don't rebuild rustdoc and clippy after checking bootstrap)
 - rust-lang#84530 (`test tidy` should ignore alternative `build` dir patterns)
 - rust-lang#84531 (Ignore commented out lines when finding features)
 - rust-lang#84540 (Build sanitizers for x86_64-unknown-linux-musl)
 - rust-lang#84555 (Set `backtrace-on-ice` by default for compiler and codegen profiles)
 - rust-lang#84585 (Add `x.py check src/librustdoc` as an alias for `x.py check src/tools/rustdoc`)
 - rust-lang#84636 (rustdoc: change aliases attribute to data-aliases)
 - rust-lang#84646 (Add some regression tests related to rust-lang#82494)
 - rust-lang#84661 (Remove extra word in `rustc_mir` docs)
 - rust-lang#84663 (Remove `DropGuard` in `sys::windows::process` and use `StaticMutex` instead)
 - rust-lang#84668 (Update books)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit dbfe0e9 into rust-lang:master Apr 29, 2021
@rustbot rustbot added this to the 1.53.0 milestone Apr 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-contributor-roadblock Area: Makes things more difficult for new contributors to rust itself S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants