[vcpkg] Fix MSBuild regressions #12062 and #12086.

[ras0219]

This PR also renames the VcpkgUserTriplet MSBuild variable to VcpkgTriplet to minimize user confusion compared to previous practice and documentation.

• What does your PR fix?
  Fixes Feature that adds vcpkg item to project settings in visual studio breaks builds that set VcpkgTriplet in .vcxproj, introduces other odd behaviors #12062 and Unable to build any package due to invalid path to vcpkg (missing platform in triplet name) #12086.

@aggieNick02 I'd appreciate any review or confirmation you can offer that this indeed fixes the issues

[aggieNick02]

I think renaming VcpkgUserTriplet to something like VcpkgDefaultTriplet would be useful here, since that is the purpose it is fulfilling in this file.

[BillyONeal]

Alternately, given Robert's rationale for ignoring other settings when the triplet is explicitly specified perhaps VcpkgUserTriplet should just go away?

[aggieNick02]

I think that is fine, but the UI would need to indicate that is what is happening. Right now it doesn't. And do we want to ignore all settings or just the static one?

The UI would need to have a boolean toggle that when true allows editing the triplet and disables all fields that are ignored when the triplet is explicitly specified, and when false disables the freeform triplet field and enables the fields that only apply when you don't explicitly specify the triplet

[aggieNick02]

This test file should cover exactly how I am currently using vcpkg, so thank you for adding it.

[aggieNick02]

So I think the behavior has improved in some cases but some more nuanced ones are still problematic. The simple case of having a VcpkgTriplet specified by manually editing the vcxproj file (the only way we used to have available) now seems to work fine and be respected, tested in both vs2015 and vs2019.

I've not had a chance to solidly reproduce the problematic or confusing behaviors and may not get to until Monday, but here is the gist of them:

1. Just cloning the repo at HEAD without this PR, my steps to reproduce no longer worked in vs2015. Instead, vs2015 seemed to be respecting whatever I had configured by hand in the vcxproj. I'm guessing something else must have changed. The steps did still work with VS2019 so the PR definitely fixes my issue, which still exists prior to it, in VS2019.
2. If you have something configured in the vcxproj file by hand, and then you play with the vcpkg project settings, things like the option to use static libraries are not honored. The properties and any changes to them are reflected in the GUI and vcxproj, but some are written in the global section, and others in a vcpkg labeled section. And when you build the things like the static option are ignored. The manual vcxproj editing and GUI options don't have to be perfectly aligned, but they should at least play nice together at some level. Right now it gets really confusing.
3. Some change removed printing out the triplet when a build starts. I really liked seeing that. I realize some people may find that noisy, but it was nice to see and very helpful for debugging/reproducing this kind of triplet issue. If there is a way to bring that back or opt in, sign me up. :-)

Like I said, sorry I don't have solid steps to repro some of the weirder behaviors. If you know what may have changed to make vs2015 start working without this PR, please let me know. I'll let you know when I do have solid steps to reproduce.

[aggieNick02]

Also, if you'd prefer to just push this PR in and then have me followup with a new issue for the more nuanced stuff I'm seeing, of course feel free to do that.

[Neumann-A]

Some change removed printing out the triplet when a build starts. I really liked seeing that. I realize some people may find that noisy, but it was nice to see and very helpful for debugging/reproducing this kind of triplet issue. If there is a way to bring that back or opt in, sign me up. :-)

was probably this one: f24543e

[BillyONeal]

Thanks for beating me to fixing this.

[BillyONeal]

I think the right fix is just to add Condition="'$(VcpkgTriplet)' == ''" to both this one and the previous one rather than deleting this.

[ras0219]

In order for VcpkgTriplet to render properly in the props pages, I believe it needs to be preset to a non-empty value in the props pages. Therefore, == '' won't work here.

[BillyONeal]

This change breaks the 'use static' option. I think the design is that VcpkgUserTriplet specifies the root, and then the static option conditionally appends -static ?

[ras0219]

This change causes 'use static' to not be appended if the user has overriden the triplet. This seemed like an unimportant interaction, because if the user has overriden the triplet they can simply specify it as "-static".

'use static' appears to primarily service the use case of wanting everything at defaults (i.e. our autodetected triplets), but static linked. Once you've overriden the triplet, I don't see the use case anymore.

[aggieNick02]

Only appending -static when the triplet isn't overridden makes for an extremely confusing and misleading UI. I really think the use static option should disappear. There are triplets which are static which do not end in static, e.g., x64-windows-static-md.

[Neumann-A]

I would highly recommend a drop down menu with the available default triplets but i don't have a clue how to do that that is why i introduced the static option

[aggieNick02]

A drop-down would be spiffy but I similarly have no idea. The list of choices is dynamic and can change when the vcpkg triplet folder changes.

[aggieNick02]

@BillyONeal Are you saying that for those that want to override the default triplet, you think 99% just want to append -static?

[BillyONeal]

@aggieNick02 Yes, because that's the only part of the triplet we don't currently guess correctly 99% of the time.

[aggieNick02]

Interesting. Curious if telemetry tells you that? I currently use static-md for most of my dependencies... I'm pretty sure that's not too uncommon, as a lot of projects (not vcpkg ports) that distribute binaries exclusively do .lib files with dynamic runtime, not static runtime.

Examples include Nvidia's CUDA and video encoding libraries and protobuf.

Is wanting a static lib with static c++ runtime really more common than wanting a static lib with dynamic runtime?

[BillyONeal]

Is wanting a static lib with static c++ runtime really more common than wanting a static lib with dynamic runtime?

That is a fairly unusual configuration: the normal reason to choose static linking is to avoid needing to deploy lots of DLLs, but under /MD you still have to deploy a bunch of DLLs.

[aggieNick02]

That is a fairly unusual configuration: the normal reason to choose static linking is to avoid needing to deploy lots of DLLs, but under /MD you still have to deploy a bunch of DLLs.

But /MD just means the visual studio c++ runtime is linked dynamically. You just need to ensure your installer installs the visual studio runtime, and nothing else.

When I create a new static library project in VS 2019, it is /MD by default. Honestly that would make me expect the default static triplets to be /MD, and a specialization be required (static-mt) if I wanted the runtime statically linked.

[aggieNick02]

@BillyONeal classified the use static option not working well. Examples of other things that either don't work after this PR

1. If I've got a project where VcpkgTriplet has been configured manually in the global section of the vcxproj, then the vcpkg project UI reflects that, but doesn't behave correctly if I try to update the triplet in the UI. For example, take a project with <VcpkgTriplet>aaa</VcpkgTriplet> in the Globals section of the vcxproj. Open it in VS2019 and open the vcpkg property page for it. Set the configuration in the property page to Debug|Win32 and then change the triplet in the UI to bbb and select OK. Build the solution to force the project to save and then examine it in notepad. You'll see the VcpkgTriplet has been updated in the Globals section, which means it has been set to `bbb for all configurations. This is not what the user requested, so that's bad.

2. In VS2015, new console project with x86-minhook-static already installed, #include "minhook.h", change project properties to use static for vcpkg. Build. It fails. Still uses x86-windows instead of x86-windows-static for some reason. (Note this is not when I've set VcpkgTriplet to anything manually or otherwise in the project file. In VS2019 the exact same sequence of steps works fine.)

I think having the option in the UI is the right long-term direction, but every day it is present with these bugs, along with inconsistencies (like use static only applying sometimes) is just going to confuse users. And it needs to work correctly with existing projects that had the triplet specified manually. My preference would be to disable the UI until we are sure it is solid and well-defined.

[BillyONeal]

I still don't think this is quite right but it's an improvement over what we were doing before.

[ras0219-msft]

Thank you everyone for the continued feedback on this; I think there is still further improvement to be made, but I want to fix the regressions we know how to fix before tackling further work :)

As always, we're happy to review any PRs to make things better.