Try to detect VS2017 using vswhere #192
Conversation
|
/cc @KindDragon |
src/engine/guess_toolset.bat
Outdated
| set VSWHERE="%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" | ||
| if not exist %VSWHERE% set VSWHERE="%ProgramFiles%\Microsoft Visual Studio\Installer\vswhere.exe" | ||
| if not exist %VSWHERE% goto :skip_vswhere | ||
| for /f "usebackq tokens=*" %%i in (`%VSWHERE% -latest -products %VSWHERE_IDS% %VSWHERE_REQ% %VSWHERE_PRP%`) do ( |
There was a problem hiding this comment.
Thanks for ping. I think better use -products * instead of IDS and add version here -version "[15.0,16.0)"
%VSWHERE% -latest -version "[15.0,16.0)" -products * %VSWHERE_REQ% %VSWHERE_PRP%
There was a problem hiding this comment.
ASAIK -products * does not cover "Buildtools" ;( (microsoft/vswhere#8) but I'll check.
-latest is supposed to be kinda similar to -version "[15.0,16.0)", no?
There was a problem hiding this comment.
ASAIK -products * does not cover "Buildtools" ;( (microsoft/vswhere#8) but I'll check.
Without -products does not cover "Buildtools", but -products * cover all products microsoft/vswhere#23
-latest is supposed to be kinda similar to -version "[15.0,16.0)", no?
"-latest" will find even theoretical "Visual Studio 2018/2019" (> 16.0). I think we should limit to VS2017 only
There was a problem hiding this comment.
As future proofing, If i find a have to better detect and set "BOOST_JAM_TOOLSET=vc141" I'd rather remove the version limit... So the code will continue to work without changes.
Sound reasonable?
There was a problem hiding this comment.
I did not fully understand. If you remove version limit and theoretical VS2019 will be with toolset "vc150", then we set "BOOST_JAM_TOOLSET=vc141" when bjam will use new toolset from VS2019
There was a problem hiding this comment.
If for vs2019/vc150 I can detect the vc150 and set BOOST_JAM_TOOLSET=vc150 bjam will fail ("unknown toolset vc150")
But this code will not need to change
There was a problem hiding this comment.
If you call vswhere without -version "[15.0,16.0)" it will set BOOST_JAM_TOOLSET=vc141, VS150COMNTOOLS (BOOST_JAM_TOOLSET_ROOT) will be set to VS2019 and bjam continue with wrong VS
src/engine/guess_toolset.bat
Outdated
| for /f "usebackq tokens=*" %%i in (`%VSWHERE% -latest -products %VSWHERE_IDS% %VSWHERE_REQ% %VSWHERE_PRP%`) do ( | ||
| set "VS150COMNTOOLS=%%i" | ||
| set "BOOST_JAM_TOOLSET=vc141" | ||
| set "BOOST_JAM_TOOLSET_ROOT=%%i\VC\" |
There was a problem hiding this comment.
Please also add BOOST_JAM_TOOLSET_ROOT detection to config_toolset.bat
build/src/engine/config_toolset.bat
Lines 168 to 171 in d2ff572
It will be used if user call build.bat vc141
|
@KindDragon addressed |
|
@refack AppVeyour show message 2 times: "The system cannot find the batch label specified - skip_vswhere" |
Although I see it's not fatal, I fixed it. |
|
Can you rebase on top of latest changes to fix AppVeyor? |
|
@KindDragon done. |
|
Hi @grafikrobot. Do you have any news about this PR? |
|
🎉 |
|
Sorry it took so long had to read it carefully and try it out and I had gobs of other things on my plate.. But even with being careful it still messed up the builds. Looks like for anything non-141 it fails to do the general bootstrap.bat procedure to build b2.exe. For example https://ci.appveyor.com/project/boostorg/boost/build/1.0.3013/job/0q1y55yeq0xauy7f#L24 |
|
I'm looking into it right now. |
Simple try/fail to use
vswhereA little bit more help to solve #157