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

Have compilation context info available earlier in the build process #5348

Merged
merged 11 commits into from
Apr 12, 2018

Conversation

djc
Copy link
Contributor

@djc djc commented Apr 11, 2018

Eventually, I hope this will allow us to ignore platform-specific dependencies when irrelevant for the current build earlier in the process. This should save on extraneous errors. As is, this seems like it already decreases coupling in the code base.

@rust-highfive
Copy link

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

@matklad
Copy link
Member

matklad commented Apr 11, 2018

@bors r+

@bors
Copy link
Collaborator

bors commented Apr 11, 2018

📌 Commit 84eb12f has been approved by matklad

@bors
Copy link
Collaborator

bors commented Apr 11, 2018

⌛ Testing commit 84eb12f7d2e0aa30c40bb524d46690b2275aaab4 with merge 43308b5990ef0662dc0305eb80459de9ce93289b...

@bors
Copy link
Collaborator

bors commented Apr 11, 2018

💔 Test failed - status-travis

Ok(BuildConfig {
host_triple: host_triple.to_string(),
requested_target: (*requested_target).clone(),
jobs: 1,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's pass in jobs: Option<u32>?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason I didn't do that is that passing None explicitly always feels mostly ugly, especially in this situation where there are only two callers, and 1 seems pretty defensible as a default. All the fields of the struct are already being modified, anyway.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(But if you insist, sure!)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was going to argue that 1 is a completely wrong default here, and we should just use num_cpus, but looks like we already use 1 in clean, so I am actually fine with it now :-)

@djc
Copy link
Contributor Author

djc commented Apr 11, 2018

So that last one went a little bit crazy. It does seem like this is much clearer about the actual workings, though, in that cargo_rustc did actually not represent any command, but had a whole bunch of code related to driving the compiler, which seems to make more sense in core.

@matklad
Copy link
Member

matklad commented Apr 11, 2018

This looks great to me, but let's also ask @alexcrichton about this refacrtoring!

@matklad
Copy link
Member

matklad commented Apr 11, 2018

It also seems like RLS might need updating after this PR as well: they use cargo as a library, and so are pretty sensitive to internal organization.

@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Collaborator

bors commented Apr 12, 2018

📌 Commit a340ba0 has been approved by alexcrichton

@bors
Copy link
Collaborator

bors commented Apr 12, 2018

⌛ Testing commit a340ba0 with merge 827bf05...

bors added a commit that referenced this pull request Apr 12, 2018
Have compilation context info available earlier in the build process

Eventually, I hope this will allow us to ignore platform-specific dependencies when irrelevant for the current build earlier in the process. This should save on extraneous errors. As is, this seems like it already decreases coupling in the code base.
@bors
Copy link
Collaborator

bors commented Apr 12, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 827bf05 to master...

@bors bors merged commit a340ba0 into rust-lang:master Apr 12, 2018
@ehuss ehuss added this to the 1.27.0 milestone Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants