Multiple values for --triplet and %VCPKG_DEFAULT_TRIPLET%

[vrubleg]

I usually install a every new library for 4 different triplets: x86-windows-static,x64-windows-static,x86-windows-crtdll,x64-windows-crtdll (crtdll is for VCPKG_CRT_LINKAGE=dynamic and VCPKG_LIBRARY_LINKAGE=static, I would provide it as a preinstalled option). And it takes time to type something like:

vcpkg install fmt:x64-windows-crtdll fmt:x64-windows-static fmt:x86-windows-crtdll fmt:x86-windows-static

I propose to add support specifying of multiple triplets in the --triplet argument:

vcpkg install fmt --triplet x64-windows-crtdll;x64-windows-static;x86-windows-crtdll;x86-windows-static

And to make it even better, please support multiple triplets in the %VCPKG_DEFAULT_TRIPLET% environment variable, like this:

set VCPKG_DEFAULT_TRIPLET=x64-windows-crtdll;x64-windows-static;x86-windows-crtdll;x86-windows-static
vcpkg install fmt

; is usually used as a delimiter for environment variables, but , could be supported also.

[seven-mile]

Did vcpkg make any progress on this issue? I hope my build tools can find packages by some specific priority, too...

[vrubleg]

@seven-mile seems like the developers didn't notice this suggestion yet, or just don't like this idea for some reason.

[seven-mile]

Emm...Several days ago this issue was moved to a discussion, I think they may have been considering it~

[vrubleg]

As for me, it sounds more like "you can discuss it, but we don't want to have it as an opened ticket in our backlog".

[jdx-john]

I definitely like this idea. If you are using manifest files, you must run vcpk multiple times - once per triplet (as far as I can see). A single command would be far neater.

[bysju]

I have a visual studio project that builds x64(static) and x86(static) binaries and uses vcpkg as manifest mode.
When I change platform(x64 <-> x86) and start to build, vcpkg -install runs and removes library files related to the previous triplet.

>"C:\vcpkg\scripts\buildsystems\msbuild\..\..\..\vcpkg.exe" install  --x-wait-for-lock --triplet "x64-windows-static" --vcpkg-root...
1>Detecting compiler hash for triplet x64-windows-static...
1>The following packages will be removed:
1>    boost-algorithm:x86-windows-static
...

It consumes time.
I didn't find how to both(x64-windows-static & x86-windows-static) exist at the same time in manifest mode.
I hope this idea also could solve this issue.

[AugP]

My project is set up with manifest mode and then we run vcpkg install --triplet=<TRIPLET> for each of our target platforms. We use recent version of vcpkg obtained by cloning the source and then running bootstrap-vcpkg.bat. With this set up, vcpkg continues to remove old triplet's builds. Is this the expected behavior?

I have started a discussion with the team about revisiting this experience. We should have a clean solution for supporting multiple triplets without deleting/bringing back files all the time.

[nathan-stouffer-onx]

Awesome, I will keep an eye on this discussion page!

[autoantwort]

We should have a clean solution for supporting multiple triplets without deleting/bringing back files all the time.

This already works if you don't manually run vcpkg install and use manifest mode and the msbuild integration.

[hmoffatt]

I ended up using vcpkg's --x-install-root switch for this. You have to run once for each triplet with the two different roots specified, but it works. At least in the old vcpkg version I'm using.

[dg0yt]

My project is set up with manifest mode and then we run vcpkg install --triplet=<TRIPLET> for each of our target platforms.

FTR if you run vcpkg install --triplet=<TRIPLET> for manifest mode in the source directory, it behaves different from being run automatically in binary directories. (In simply doesn't know the binary directory at this point.)

[AbdulAbCellera]

Hi, just checking if there has been any progress on this.

[vrubleg]

because you simply cannot link both at the same time into the same output binary.

But you can have different project configurations in the same project.

[Neumann-A]

But you can have different project configurations in the same project.

The triplet is part of the configuration so you can also change triplets as needed as part of the configuration.

[dg0yt]

You cannot have both types of linkage for a single port in a single triplet. However, you are allowed to change the linkage for individual ports in a customized triplet. Triplet files are official customization points.
https://learn.microsoft.com/en-us/vcpkg/users/triplets#per-port-customization

[davidhunter22]

Maybe I wasn't clear. Imagine I create a CMake project that contains two targets which produce executables. The targets are completely independent. When I generate, say a Visual Solution, from this CMake I get two Visual Studio projects which are also totally independent.
Now in one of these targets I want to use the dynamic library for a given port, lets say pugixml, so I want to do target_link_libraries(target_1 PUBLIC pugixml::pugixml). In the other I want to use the static version so target_link_libraries(target_2 PUBLIC pugixml::static). So I am not trying to mix stuff in the same binary.
To me this a perfectly valid use case and one I have run into a number of times.
Now as far as I understand using a vcpkg manifest there is no way to do this. I can't use an overlay because it's the same port. I have tried everything I can think of and have read. For instance I believe you can't have different values of VCPKG_TARGET_TRIPLET used in different CMake targets.
Maybe there is a way to do this, if so I would love to know how as this issue stops us using vcpkg in various reasonable scenarios.

My personal view is that my triplet should be x64-windows and I should be able to use both the static and the dynamic version of the library as I see fit.

[dg0yt]

Your particular case may be perfectly valid and reasonable. OTOH there is a number of packages which build together well, or are usable conveniently in msbuild, because vcpkg burns the single linkage type into the header, for declspec(dllimport). Also find_library or target_link_libraries(foo bar) could be quite fragile in some packages if both libs are available. So what is a barrier for your desired configuration has a huge benefit on other configurations.

But mixing linkage in one triplet is off-topic for the original discussion here.

[eabase]

Seem vaguely related to my question: #46983