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

Bootstrap: detect Windows based on sys.platform #73691

Merged
merged 1 commit into from
Jun 27, 2020

Conversation

ajpaverd
Copy link
Contributor

Closes #73689.

@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 Jun 24, 2020
@retep998
Copy link
Member

What effect does this have on the branches where we detect MSYS/MinGW to build pc-windows-gnu?

@mati865
Copy link
Contributor

mati865 commented Jun 25, 2020

What effect does this have on the branches where we detect MSYS/MinGW to build pc-windows-gnu?

It's going to build x86_64-pc-windows-msvc unless the target was was explicitly set. This doesn't seem right.

@retep998
Copy link
Member

Perhaps we could move the pc-windows-msvc fallback to the end of the ostype if chain, where if none of the ostypes match but sys.platform says we are windows then we use x86-64-pc-windows-msvc, otherwise we error.

@ajpaverd
Copy link
Contributor Author

Perhaps we could move the pc-windows-msvc fallback to the end of the ostype if chain, where if none of the ostypes match but sys.platform says we are windows then we use x86-64-pc-windows-msvc, otherwise we error.

Sorry for the broken patch! Yes, I was just thinking to move this fallback to the end of the ostype chain. I'll push an update soon.

# Some Windows platforms might have a `uname` command that returns a
# non-standard string (e.g. gnuwin32 tools returns `windows32`). In
# these cases, fall back to using sys.platform.
return 'x86_64-pc-windows-msvc'
Copy link
Member

Choose a reason for hiding this comment

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

Hm, is there a reason not to directly compare with windows32 here? (FWIW windows32 to me sounds like a 32-bit platform, but maybe that's historical baggage or something?)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think that's historical baggage of the gnuwin32 tools (they also return i686-pc for uname -m even on a 64-bit system). I didn't find a 64-bit equivalent, so this is probably not a reliable way to determine the actual architecture.

My thinking here was to provide a default for Windows platforms with any non-standard uname value (same as not having uname), but I can certainly change this to a direct comparison with windows32. What would be best?

Copy link
Member

Choose a reason for hiding this comment

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

Hm, so I think this is probably fine -- we can always limit the scope later, if necessary, or add more conditionals.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the review!

@Mark-Simulacrum Mark-Simulacrum added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 26, 2020
@Mark-Simulacrum
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Jun 26, 2020

📌 Commit 8b368db 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 26, 2020
Manishearth added a commit to Manishearth/rust that referenced this pull request Jun 26, 2020
…=Mark-Simulacrum

Bootstrap: detect Windows based on sys.platform

Closes rust-lang#73689.
Manishearth added a commit to Manishearth/rust that referenced this pull request Jun 26, 2020
…=Mark-Simulacrum

Bootstrap: detect Windows based on sys.platform

Closes rust-lang#73689.
Manishearth added a commit to Manishearth/rust that referenced this pull request Jun 26, 2020
…=Mark-Simulacrum

Bootstrap: detect Windows based on sys.platform

Closes rust-lang#73689.
This was referenced Jun 26, 2020
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 27, 2020
…arth

Rollup of 12 pull requests

Successful merges:

 - rust-lang#72771 (Warn if linking to a private item)
 - rust-lang#72937 (Fortanix SGX target libunwind build process changes)
 - rust-lang#73485 (Perform obligation deduplication to avoid buggy `ExistentialMismatch`)
 - rust-lang#73529 (Add liballoc impl SpecFromElem for i8)
 - rust-lang#73579 (add missing doc links)
 - rust-lang#73627 (Shortcuts for min/max on double-ended BTreeMap/BTreeSet iterators)
 - rust-lang#73691 (Bootstrap: detect Windows based on sys.platform)
 - rust-lang#73694 (Document the Self keyword)
 - rust-lang#73718 (Document the super keyword)
 - rust-lang#73728 (Document some invariants correctly/more)
 - rust-lang#73738 (Remove irrelevant comment)
 - rust-lang#73765 (Remove blank line)

Failed merges:

r? @ghost
@bors bors merged commit c18e919 into rust-lang:master Jun 27, 2020
@cuviper cuviper added this to the 1.46 milestone May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.

Bootstrap fails when Windows has uname command
7 participants