Vcpkg: Please make allowing for build options a high priority

[bagong]

I was really excited to see vcpkg emerging, as I've been waiting for the Windows homebrew alternative for a long time. But after excitedly diving in, I had to return to old practice again, unfortunately, and - I hope - temporarily. Three examples of the kind of obstacles we face:

• static builds and MT/MD: our project depends on Qt - for which the static build currently doesn't work - and which is so big that one might want to avoid linking to it statically anyways. But for other libraries one might want to do so, e.g. for portability reasons. Currently, if you try to link to smaller libraries statically and Qt dynamically, you'll get a MT/MD conflict build error. That can be avoided by building static libraries with MD too, so it would be nice to have that as build option.

• Allow for head version: we currently can't easily use flac from vcpkg, because the port version doesn't contain important (security and functionality) related fixes that have recently been committed to master.

• Allow for important project specific build options: we can't easily use fftw3 because we can't set the required math precision (there are 4 fftw3 precision versions, and each project may need a different one (Btw, traditionally these versions are distinguished by library name - this too seems not to be reproduced in the current fftw3 build).

[ras0219-msft]

Thanks for the feedback!

1. We do support static/MD, it just doesn't happen to be a triplet file that is available by default. If you look in the triplets\ directory, it should hopefully not be too complicated to either change the settings to your liking or to make a new triplet of your own (make sure to leave the "root" name in though; for example, x64-windows-bagong would be fine).
2. This is definitely something we need to improve on. Today, as a workaround, you can simply edit ports\flac\portfile.cmake to locally upgrade (or downgrade!) to any version you need. As a bonus, this approach means you can actually track a specific flac version so you get consistent results across machines and avoid heisenbuilds. As a quick dive into "git" packages though:
   
   
   
   • How would you expect "git" packages to interact with vcpkg update? Always list as outdated, never list as outdated, or ping the network every time to check?
   
   
   • Currently, vcpkg remove --outdated will remove everything listed in vcpkg update; if "git" packages should always show up in update, should remove --outdated always remove them?
   
   
   • Do you have any concerns about getting different packages every time you run install? Especially in the context of open source, where you're likely to get bug reports from users who have an unstable copy of your dependencies.
   
   
3. Similar to 2, definitely an area for improvement. Our current strategy here is that you can customize ports\fftw3\portfile.cmake to meet any local needs -- though definitely we acknowledge that this doesn't help open source projects very much!

[bagong]

Thanks a lot for your comments!

1. This is great!!! (had a small hickup, as I called "my" triplet x64-windows-staticMD and promptly got an error because the triplet name doesn't work with capitals, but that's just informational - I love the option.)
2. Providing defined build options that can be used as arguments in basic commands (like vcpkg install libflac --head or in case of fftw3 --single/--double etc) just makes things easier and provide a partial possible answer to your enquiry: if you use "official" build options defined by build arguments, an update will try to reuse them in the update. Logically that would mean a --head/"git" build should be updated each time update is run and commits were made to master. I don't feel competent to make a suggestion here, I can see it's not a trivial decision. Maybe revision could be offered as a third option next to a release and head where applicable. The option to edit the portfile easily is fab of course, and doing it in a git tree makes it even better. Homebrew offers "pin" and "switch" btw. "pin" allows to freeze a version, and "switch" to select one as default or current, if multiple versions are installed. But it took hb several years to evolve into a system that could handle variants and version well, so I am not saying it's trivial or evident.
3. Yup, but like in 2 having defined build options as part of the portfile will allow to keep customizations across updates, and not require us to interfere with the systems original state more than necessary.

Thanks again for your comments!
Great project, I hope it will catch on!

[OlafvdSpek]

Perhaps static libs with dynamic run-time should be a standard triplet. ;)

[ras0219-msft]

I've opened a PR (#1205) for a potential solution to the optional dependencies problem; please take a look and let us know any feedback!

[ras0219-msft]

With the addition of feature packages, options are now supported in Vcpkg :)