add cmakeToolchain to CMakeSettings.json

[fsb4000]

Today I tried to build STL from Visual Studio 2022 IDE (first try, before only command line)
And I had to add cmakeToolchain or I got an error: "BOOST NOT FOUND".
So I decided to contribute my changes.

[miscco]

It is a bit strange as it should already use the default vcpkg one

[fsb4000]

@miscco
Could you try to build the stl from IDE?

[miscco]

I build it just last wek with the new toolchain

[fsb4000]

Strange. I did checkout main.
And vcpkg was found: " Found and using vcpkg toolchain file (C:/tools/vcpkg/scripts/buildsystems/vcpkg.cmake)."
But I still got error:

And I have no error with the PR.
But vcpkg was found...

[fsb4000]

I got it. Without the changes it uses system vcpkg: (C:\tools\vcpkg in my case)
But stl vcpkg is C:\Dev\STL\vcpkg
Is this the expected and desired behavior that vcpkg is taken from the system and not from stl?

I think stl vcpkg is desired...

[CaseyCarter]

So, IIUC, the question here is whether we want to override the user's choice of default vcpkg instance (which IIUC the user chose via vcpkg integrate install) and redirect to our internal vcpkg by default?

[fsb4000]

yes

[fsb4000]

if we decide that it is not worth overriding the user's choice of default vcpkg then we need to update the instruction: https://github.com/microsoft/STL#how-to-build-with-the-visual-studio-ide

[barcharcraz]

how is the "system" vcpkg defined? do you set it or does VS2022 set it?

[barcharcraz]

sidenote: I have a branch that removes CmakeSettings.json and adds CMakePresets.json (which is a similar feature provided natively by cmake), however I haven't opened a PR because it's somewhat broken at the moment in vscode.

[fsb4000]

@barcharcraz I installed it myself a couple days ago.

[StephanTLavavej]

I am far from an expert here, but using our internal vcpkg by default sounds like the right thing to do. Not only does it keep the repo in a self-contained known state, but we generally require the latest version of Boost, which a global install of vcpkg might not have. That said, my intuition for how vcpkg should be used may not reflect most vcpkg users, especially IDE users.

[barcharcraz]

I am far from an expert here, but using our internal vcpkg by default sounds like the right thing to do. Not only does it keep the repo in a self-contained known state, but we generally require the latest version of Boost, which a global install of vcpkg might not have. That said, my intuition for how vcpkg should be used may not reflect most vcpkg users, especially IDE users.

by default yes, but if I understand correctly fsb4000 has set an environment variable designed to override such a default....

I think the actual solution here might be to switch to vcpkg manifest mode

[fsb4000]

fsb4000 has set an environment variable designed to override such a default

Not intentionally :)

I just did again (from new place for test):

git clone https://github.com/microsoft/vcpkg
.\vcpkg\bootstrap-vcpkg.bat
.\vcpkg\vcpkg integrate install

and it will use the place by default.

Found and using vcpkg toolchain file (C:/tools/test/vcpkg/scripts/buildsystems/vcpkg.cmake).

[barcharcraz]

I think we should either (or both)

1. adopt manifest mode, this would cause vcpkg to install the specified version of boost no matter what vcpkg installation is found.
2. document that if you run vcpkg integrate install visual studio will set the toolchain for you.

that said I don't have a huge problem with this PR, if we're all OK with overriding the vcpkg instance that the user requested by running integrate install.

[fsb4000]

It works both console and IDE.

But now dependencies located there:
C:\Dev\STL\out\build\x64\vcpkg_installed
C:\Dev\STL\out\build\x86\vcpkg_installed
etc.

When I switch between branches I usually delete the out folder(Maybe now I should delete without "vcpkg_installed" folder...)
Vcpkg will not rebuild boost and it will use caching, but there is a slight slowdown.

[fsb4000]

I am not sure about Azure Pipeline.
How does it work with vcpkg.json?
Shoud I just delete the lines?

STL/azure-devops/vcpkg-dependencies.yml

Lines 21 to 38 in a9321cf

	- task: run-vcpkg@0
	displayName: 'Run vcpkg to Install boost-build'
	condition: ne(variables.CACHE_RESTORED, 'true')
	timeoutInMinutes: 10
	inputs:
	doNotUpdateVcpkg: true
	vcpkgArguments: 'boost-build'
	vcpkgDirectory: '$(${{ parameters.vcpkgLocationVar }})'
	vcpkgTriplet: 'x86-windows'
	- task: run-vcpkg@0
	displayName: 'Run vcpkg to Install boost-math'
	condition: ne(variables.CACHE_RESTORED, 'true')
	timeoutInMinutes: 10
	inputs:
	doNotUpdateVcpkg: true
	vcpkgArguments: 'boost-math'
	vcpkgDirectory: '$(${{ parameters.vcpkgLocationVar }})'
	vcpkgTriplet: '${{ parameters.targetPlatform }}-windows'

[fsb4000]

1257354a3ab0bebd8abe95281ca561537853578c is from

cd vcpkg
git rev-parse HEAD

143 is from:

STL/stl/inc/yvals_core.h

Line 563 in a9321cf

#define _MSVC_STL_VERSION 143

[fsb4000]

now: https://dev.azure.com/vclibs/09a07da7-73b5-4bba-8263-2aad1a16c33d/_apis/build/builds/8709/logs/81
before: https://dev.azure.com/vclibs/09a07da7-73b5-4bba-8263-2aad1a16c33d/_apis/build/builds/8703/logs/83

it is definitely does not use vcpkg Caching.

+1 minute 30 seconds for every Build :(

[michael-herwig]

I think you need to update the cache hash for vcpkg.

STL/azure-devops/vcpkg-dependencies.yml

Lines 17 to 20 in 721e3ad

	inputs:
	key: '"${{ parameters.targetPlatform }}" | "$(${{ parameters.vcpkgSHAVar }})" | "2020-03-01.01"'
	path: '$(${{ parameters.vcpkgLocationVar }})/installed'
	cacheHitVar: CACHE_RESTORED

The cache hit loads a deprecated version of the vcpkg install directory. Further, the cache hit prevents the pipeline from uploading a new version of the cache.

You may want to hash the vcpkg manifest into the hash of the vpkg cache key, see documentation.

    key: '"${{ parameters.targetPlatform }}" | "$(${{ parameters.vcpkgSHAVar }})" | ${{ hashFiles('vcpkg.json') }} | "2020-03-01.01"'

Or just update the date.

[fsb4000]

after #2151 my change is not needed.