[RFC] Options 🎉

[autoantwort]

A RFC for options. Not final. Feel free to comment. I reused some sentences from https://github.com/edhebi/vcpkg/blob/master/docs/specifications/options.md. Thank you @edhebi for writing the initial RFC.

[Neumann-A]

the same as selecting qtbase[core,gui] vs qtbase[core]. A rebuild if the selection cannot be fulfilled.

[autoantwort]

Yeah, but features are additional.
If I run vcpkg install "qtbase[core,doubleconversion,zstd]"
and then vcpkg install "qtbase[core,doubleconversion]" qtbase[core,doubleconversion,zlib] and not qtbase[core,doubleconversion] is installed. With options you would "remove" the previously installed stuff because things are not additive.

[Neumann-A]

due to the fact that options are not additive they are not allowed to be specified in the manifest itself.
Otherwise conflicts within the tree might arise making stuff unbuildable.

[autoantwort]

Huh. Then you can't use options in manifest mode?

[Neumann-A]

Then you can't use options in manifest mode?

to be more precise: you don't specify dependent options in the manifest.
Think about it: if the ssl/lapack or the qt version are hardcoded into the manifest of one port which sense does it make to offer the option? Furthermore if ports have conflicting hardcoding options those won't work together. There is a reason why features need to be additive.
Maybe there needs to be a distinction between manifest in the port folder and a manifest in the build folder. Or there needs to be a variable similar to VCPKG_MANIFEST_FEATURES just for the options of every port (VCPKG_<PORT>_MANIFEST_FEATURES ?).

[autoantwort]

Think about it: if the ssl/lapack or the qt version are hardcoded into the manifest of one port which sense does it make to offer the option?

If I have a port A with an option for Qt5/6 and a port B that depends on A[qt=qt5] because B only work with Qt5 I still can use port A with Qt6 (I don't care about port B). Currently A must stick at Qt5 or we remove port B.

Furthermore if ports have conflicting hardcoding options those won't work together.

Yes, I would accept this. We already have this situation with boringssl vs openssl. You can't install them at the same time.

Maybe there needs to be a distinction between manifest in the port folder and a manifest in the build folder.

One could think about it to only allow this at "end users project" manifest files and not in port manifest files. But I would vote against it and allow it everywhere (I know that you can then create uninstallable trees).

[JackBoosY]

cc @strega-nil-ms for review this PR.

[strega-nil-ms]

So, some thoughts from the team (I should've posted this last week and forgot):

This is our first RFC from a member of the community! (excited!) That's really cool, and I'm super excited about it.

There are some considerations we have to make, though. This is a Microsoft product and we need to be able to support any features that gets added. This means justifying to management that this is worth spending developer time on. "A community member showed up and wrote an RFC" is definitely a large piece of evidence for that the feature is worth it, but it still needs to go through internal review and the like.

What we think is the right way forward is first, to get some preliminary review from the vcpkg team; then, if you're interested, we'd love an experimental implementation, behind a feature flag, in vcpkg-tool. We can go from there.

I'll be championing this feature internally, so we should probably open communications on discord or something so we can talk about it, if you like.

Thanks so, so much!

[Neumann-A]

@autoantwort Do you already have an implementation in vcpkg-tool for this ?

@strega-nil-ms what is the progress?

[BillyONeal]

@strega-nil-ms what is the progress?

https://github.com/microsoft/vcpkg/wiki/Roadmap <-- Our PM team just updated the roadmap here and it doesn't look like we'll be getting to this in the next... while. It's still something we want and I expect it to be a high priority next time additional capabilities for ports are under consideration.

[vicroms]

Related PRs:

• [libdatachannel] feat(libnice): added libnice feat #26712
• [tinygltf] Enable usage variants #24712

(🤔 those two end with 712... coincidence?)

PRs with triplet variables that could potentially have been options:

• [osg] Added OPENGL_PROFILE option to osg port as a triplet variable. #24108
• [nlohmann-json] Add option to control implicit conversions behaviour #22409
• Neumann-A's X libraries series of PRs ([wayland] add ports for wayland.  #26475, [xwindow] part 3/n #26572, [Xwindow] part 5/N #26684, [xwindow] part 5b #26851, etc.)

[autoantwort]

@autoantwort Do you already have an implementation in vcpkg-tool for this ?

I am considering making one. Shouldn't be too hard™️

[Osyotr]

I think this is the use case: #37450
I.e. need something like:

{
  "name": "curl",
  "features": {
    "http3": {
      "description": "HTTP3 support",
      "options": {
        "backend": { 
          "choices": [
            {
              "name": "ngtcp2",
              "dependencies": [,
                "nghttp3",
                "ngtcp2",
                "probably requires nested options to choose between quictls/gnutls/wolfssl?"
              ]
            },
            {
              "name": "openssl",
              "dependencies": [
                "nghttp3",
                {
                  "name": "curl",
                  "options": {
                    {
                      "name": "ssl-backends",
                      "value": "openssl",
                      "exclusive": true
                    }
                  }
                },
                {
                  "name": "openssl",
                  "version>=": "3.2.0"
                }
              ]
            }
          ],
          "default": "ngtcp2"
        }
      }      
    }
  }
}