Closed pps83 closed 3 months ago
The minimal fix is:
diff --git a/src/tools/msvc.jam b/src/tools/msvc.jam
index f56f1cedb..7862e9988 100644
--- a/src/tools/msvc.jam
+++ b/src/tools/msvc.jam
@@ -1119,7 +1119,7 @@ local rule generate-setup-cmd ( version : command : parent : options * : cpu : g
}
else
{
- if [ MATCH "(14.3)" : $(version) ]
+ if [ MATCH "(14.[34])" : $(version) ]
{
if $(.debug-configuration)
{
But ideally a new version msvc-14.4
should be introduced, I guess. On the other hand, this is a case where a 'minor' update of Visual Studio 2022, namely going from v17.9 to v17.10, introduces a 'new' toolchain version starting with 14.40
.
E.g., I don't think there is a way to install both v17.9 and v17.10 side-by-side, so b2's msvc-14.3
would still indicate "whatever the current version of Visual Studio 2022 is".
In that case, the fix above would probably be enough for the time being, until Microsoft releases e.g. Visual Studio 2024 and bumps the toolchain version to 14.5 or even 15.0 ...
@Kojoley @grafikrobot what's your opinion on this?
But ideally a new version
msvc-14.4
should be introduced, I guess. On the other hand, this is a case where a 'minor' update of Visual Studio 2022, namely going from v17.9 to v17.10, introduces a 'new' toolchain version starting with14.40
.
Not sure there is a version bump, but preview isn't a minor update. Many fixes (including one I need) aren't released in regular updates, but preview often has them
But ideally a new version
msvc-14.4
should be introduced, I guess. On the other hand, this is a case where a 'minor' update of Visual Studio 2022, namely going from v17.9 to v17.10, introduces a 'new' toolchain version starting with14.40
.Not sure there is a version bump, but preview isn't a minor update. Many fixes (including one I need) aren't released in regular updates, but preview often has them
Yeah, but b2
typically handles major Visual Studio versions as different msvc-*
toolsets. E.g.:
Normally you would expect the "14.4" version only for Visual Studio 2024 (or 2025, not sure what MS's plans are). Not for a preview version of the next minor update of Visual Studio 2022.
The (MSVC) toolset remains at version v143 in VS 17.10, so the (b2) toolset should still be msvc-14.3.
It's not clear what MS will decide to do for the next version of Visual Studio, but if they break ABI (at last) it would probably be msvc-15.0 on our end. If not, we'll need to decide whether to go with msvc-14.4 or msvc-14.5. :-)
The (MSVC) toolset remains at version v143 in VS 17.10
Is it though? It tells its version as 14.40.33807.
Yes, see the screenshots in https://devblogs.microsoft.com/cppblog/msvc-toolset-minor-version-number-14-40-in-vs-2022-v17-10/
Even though it identifies as 14.40.something, it still is a minor Visual Studio 2022 update, and it behaves exactly the same as the 14.39. and 14.38. versions before it. On the other hand, the blog Peter just pointed to seems to indicate that it might be possible to have both installed side-by-side?
Indeed, it looks like you can do that explicitly now (this is a screenshot of the Visual Studio Installer's "Individual components" tab):
but I don't think b2 ever supported picking any of these fine-grained versions?
Side by side is unrelated to this; you can also have 14.38 and 14.39 installed side by side. They are still all "platform toolset Visual Studio 2022 (v143)". (Whereas e.g. 14.24, which you can also have, is "platform toolset Visual Studio 2019 (v142)".
I cannot express my feelings about the version bullshit microsoft creates for every their product. The compiler already has like 3 distinct versions simultaneously, now we again have to square the circle.
Well, I just installed the "v14.39-17.9" component, and I now have both 14.39.33519
and 14.40.33807
in my MSVC directory:
Directory of C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\*
2024-05-23 17:00 <DIR> 14.39.33519
2024-05-23 15:21 <DIR> 14.40.33807
It looks like msvc.jam
now chooses the first one, always. I don't see a way to tell it to use one or the other.
With vcvars64.bat
, you can at least pass -vcvars_ver=14.40.33807
to pick the one you want.
The compiler already has like 3 distinct versions simultaneously
Make that 4 if counting the Visual Studio version (17.10).
It is what it is.
I don't see a way to tell it to use one or the other.
There has never been such a way and I've never missed it. We just need to tell b2 that 14.4x is still msvc-14.3 and be done with it.
Yes, I've submitted https://github.com/bfgroup/b2/pull/394 for this.
Environment and version details
I've always used the same build command to build boost:
Today, I downloaded boost 1.85 and for the first time in many years build failed:
...
I tried all kinds of things, but it just always fails with that same error. Then, my suspicion was that boost build has issue with the
VS2022 Preview
and it seems to be the case: I downloaded boost 1.84 (that's the last version I have built locally with that same command I mentioned above). I tried to build 1.84 and I got exactly the same error, which makes me believe that boost build has some some sort of issue withVS2022 Preview
. I have both VS2022 pro, and VS2022 Preview installed. Somewhat unusual perhaps about my install is that VS2022 is installed inC:\
drive, while VS2022 Preview is installed inD:\
drive.Attached boost185-build.txt contains output when I tried to open vs2022 developer console and build: boost185-build.txt. Same error happens if I opens vs2022 preview developer console, or plain cmd.exe