-
-
Notifications
You must be signed in to change notification settings - Fork 133
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
fix: detect preview versions of msvs #269
base: main
Are you sure you want to change the base?
Conversation
cpython-windows/build.py
Outdated
] | ||
p = subprocess.check_output(cmdline) | ||
if not p: | ||
cmd = " ".join('"%s"' % i for i in cmdline) |
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.
Is there a reason to quote each item in the invocation? I feel like it'd probably be more readable without.
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 was trying to balance between copy-pasteability and complexity. The first argument is typically going to have multiple spaces in it :/
"C:\Program Files (x86)\Microsoft\Visual Studio 2019".. le sigh :( Quoting only the ones that have spaces in is doable but kind of hard to read:
cmd = " ".join([
'"%s"' if ' ' in i else i
for i in cmdline
])
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.
shlex.join
may be what you're looking for. The quoting isn't designed for non-POSIX shells but should do the job for pretty-printing.
Thanks for contributing! |
Is there a compelling reason to support building with prerelease versions of Visual Studio? |
p = pathlib.Path(p.strip().decode("utf-8")) | ||
p = p.strip().decode("utf-8") | ||
if "\n" in p: # more than one line | ||
print("found multiple matching instances of visual studio %s:" % msvc_version) |
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.
So this is like: you have 2022 and the 2022 pre-release installed? Should we just... pick one? (If you know) are they ordered?
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.
There are two options:
-latest Return only the newest version and last installed.
-sort Sorts the instances from newest version and last installed to oldest.
When used with "find", first instances are sorted then files are sorted lexigraphically.
outputs (removing the -version so it shows both my installs; not quite sure I trust ms's installer enough to risk installing vs2022 proper with 19 tools and 22 preview at the same time)
E:\>"C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe" -property installationPath -prerelease -products *
C:\Program Files\Microsoft Visual Studio\2022\Preview
C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools
E:\>"C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe" -property installationPath -prerelease -products * -sort
C:\Program Files\Microsoft Visual Studio\2022\Preview
C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools
E:\>"C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe" -property installationPath -prerelease -products * -latest
C:\Program Files\Microsoft Visual Studio\2022\Preview
ergo we could use '-latest', but that's not really solving the problem, just another python-related booby trap for the poor SOB who got the "make it work on windows" ticket...
It would be nice if running this from a devshell could just use the current environmented visual studio, but I lost that fight several times trying to do something similar with our studio's python-based cmake wrapper and haven't had the courage to revisit it since finding using powershell was a sufficient workaround =/
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.
Sorry, can you clarify why using -latest
isn't really solving the problem?
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 I've been building time-and-again with C++X language features only available in the Preview edition and then it suddenly fails on me because it transparently switched to using the latest update of the Build Tools release, that's going to be a head scratcher, especially if it was an automatic update nobody manually triggered.
If they have multiple installs of the same edition, I'm sure they're expecting to have a switch of some kind for it, but I don't really want to explode this diff into tackling that.
It's not uncommon for canary builders or ci machines to have multiple VS variants of the same edition installed: 1/ VS 2022 Build Tools, 2/ VS 2022 Professional, 3/ VS 2022 Ultimate Preview, or if they have 4/ a Community Edition installed that gives them licensing considerations.
Ah - I can see why you might wonder that; "prerelease" recognizes the "Preview" aka canary editions. Which is not the same as whatever alpha or beta of 2024 or 2025 might eventually come into existence. This is a fairly common pattern: Stable + Firehose. |
fixes indygreg#268 - add the '-prerelease' flag to the vswhere subcommand, - give 'no vs found' error if the command returns empty string, - catch vswhere returning multiple installations, - in-case of failure, report vswhere command line, placing any arguments that contain spaces in quotes
fixes #268