better management of multiple builds

[terrylyons]

---

Streamlining working with multiple toolkits
1207 asked about this. That discussion was good but left open the question of automating and so standardising the process of maintaining builds for all the versions of visual studio at once.
Two fudges that are useful for this
`
C:\dev_pkgs\Vcpkg\vcpkg>type vcpkg.bat

@for %%a in (triplets\x??-windows*) do @vcpkg %*:%%~na`

Runs vcpkg for every windows triplet in your installation,
The following batch file should only be run once but adds triplets for each of the toolkit supported for every triplet in the triplets folder that is targeted at classic windows.

`
C:\dev_pkgs\Vcpkg\vcpkg>type add_toolset_number.bat

@echo off

mkdir triplets\temp

for /L %%A in (140 1 142) do (

for %%B in (triplets\x??-windows*) do (

    echo set^(VCPKG_PLATFORM_TOOLSET v%%A^)>%%~pBtemp\%%~nB-v%%A.cmake

    type %%B>>%%~pBtemp\%%~nB-v%%A.cmake
    )

)

copy /Y triplets\temp* triplets\

rmdir /S /Q triplets\temp

`
No doubt it can be improved and should only be run once. But it saves hours compared with manually doing these things. Making libraries for the different toolkits is very time consuming and builds take time and require continuous attention. Now one can introduce boost, go to bed, and several gigabytes later it is all done.

Why bother
I am long experienced at using C++ libraries like those managed by vcpkg in a visual studio environment. I have noticed that the different model for software development in Linux (current version is king) and windows (old software still runs well) place different burdens on developers and users. One has to work with the compilers that built the tool. Python 2.7 = v9.0 etc. or each particular version of cuda has its own version of visual studio required. The developer does not get to choose their toolset! Having libraries that just work uniformly across the different toolsets is hugely valuable (even essential) and is a complex challenge as one needs so many. Still if you do really develop for existing contexts it is invaluable that tools cope with this and well worth the gigabytes that boost generates etc. Thankfully building libraries is something one does only occasionally.

props files
These work very well with visual studio and libraries outside the solution space and can be checked in for other users. props files for libraries don't work well with public repositories. Hopefully vcpkg will do much better.

Beginner Thoughts
vcpkg remove needs wild cards
how do I find out if the intel-mkl x64 is the IPL64 or LP64 calling interface.

Hope the batch files help someone.

[terrylyons]

example code for props files for boost