-
Notifications
You must be signed in to change notification settings - Fork 2
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
feat: setup bootstrap and ci #3
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left some minor nits. I also have a question for this backend: is there a reason why you need to reinvent a bootstrap instead of forking the rust
repo then adding additional logic as necessary?
EDIT: to clarify, it's entirely possible that you have very good reasons or run into difficult limitations for doing so. I'm asking because using Yet Another Bootstrap makes (1) upstreaming the backend very very difficult and (2) makes it more difficult for other rustc contributors who wants to make changes to this backend because they have to deal with the intricacies of Yet Another Build System.
In projects such as rustc_codegen_cranelift or rust_codegen_gcc, there exists a component referred to as the |
Refer to #2 (comment) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks pretty good overall. Please just make sure absolute paths are used everywhere, otherwise it looks like a lot of things will break when running from a different directory.
Aside from that, a few other comments but I don't see any big issues.
run: | | ||
rustup update nightly --no-self-update | ||
rustup default nightly | ||
rustup component add clippy | ||
run: rustup show |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should be able to use rustup toolchain install
to make sure the version from the toolchain file is used, since rust-lang/rustup#3983
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feature is not yet available in the release version of rustup. Perhaps we can wait for the next release of rustup before switching the approach here.
|
||
impl CleanCommand { | ||
pub fn run(&self, manifest: &Manifest) { | ||
let _ = std::fs::remove_dir_all("crates/target"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be an absolute path presumably based on location information in Manifest
, so running from a different location doesn't remove the wrong thing.
.args(["--manifest-path", "bootstrap/Cargo.toml"]), | ||
); | ||
self.perform( | ||
Command::new("cargo") | ||
.arg("fmt") | ||
.args(["--manifest-path", "crates/Cargo.toml"]) | ||
.arg("--all"), | ||
); | ||
for file in glob("example/**/*.rs").unwrap() { | ||
self.perform( | ||
Command::new("rustfmt") | ||
.args(["--edition", "2021"]) | ||
.arg(file.unwrap()), | ||
); | ||
} | ||
for file in glob("tests/**/*.rs").unwrap() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should use absolute paths too.
} | ||
} | ||
|
||
pub fn perform(&self, command: &mut Command) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: perform
and run
should probably get different names since it isn't very obvious what the difference is. Or ideally, just put this into a trait so all steps are required to use the same interface.
Nonblocker though, this can be changed later.
/// debug mode | ||
#[arg(short, long)] | ||
pub debug: bool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could probably be called verbose
based on how it is use. debug
sounds like it would be the opposite of release
.
pub out_dir: PathBuf, | ||
} | ||
|
||
impl Manifest { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Double check that absolute paths are used in this block
"FileCheck", | ||
"FileCheck-14", | ||
"FileCheck-15", | ||
"FileCheck-16", | ||
"FileCheck-17", | ||
"FileCheck-18", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: you probably want to reverse the order so newer filecheck versions get preferred?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One additional question: Should we prefer FileCheck
or FileCheck-18
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you can be specific, then pinning it to a specific FileCheck version seems nicer for reproducibility (and bumps to which FileCheck version is used then becomes explicit)
The use cases for bootstrap are typically highly specific to the project structure, making execution in alternative directories impractical. Additionally, the brevity of the As far as I am aware, |
This pull request sets up the bootstrap process and CI for the C codegen backend.