set paths with environment variables rather than command line arguments

[Be-ing]

Is your feature request related to a problem? Please describe. Currently vcpkg has the following command line arguments available:

  --x-buildtrees-root=<path>      (Experimental) Specify the buildtrees root directory
  --x-install-root=<path>         (Experimental) Specify the install root directory
  --x-packages-root=<path>        (Experimental) Specify the packages root directory
  --x-scripts-root=<path>         (Experimental) Specify the scripts root directory
  --x-builtin-ports-root=<path>   (Experimental) Specify the packages root directory
  --x-builtin-registry-versions-dir=<path>
                                  (Experimental) Specify the versions root directory

Reusing these between multiple invocations of vcpkg requires retyping the same arguments repeatedly which is cumbersome.

Proposed solution Let the user set these paths with environment variables. This would allow setting them once in the shell so they don't have to be retyped for each invocation of vcpkg.

Describe alternatives you've considered :shrug:

Additional context Other vcpkg options can be set by environment variables, for example VCPKG_OVERLAY_PORTS.

[JackBoosY]

cc @ras0219

[StarGate-One]

Another option would be to write custom scripts using powershell core, bash, etc where all these command line options are already set and the port[features] are passed into the script from a data file building. I myself just completed re-writing a series of scripts used by me from cmd to powershell core, takes a vanilla vcpkg and vcpkg-tool instance, copies them to local customized instances, from the vanilla clone up to creating a list of all available ports along with a list of installed ports, not to mention eliminating the dreaded vcpkg upgrade --no-dry-run which fails periodically leaving one's instance is a half-built state requiring much manual intervention, and has not been maintained with options currently available to the vcpkg install.

[Be-ing]

That's a really ugly workaround IMO.

[StarGate-One]

Guess it depends on one's perspective? One says ugly the other says elegant. It works until ~when~ if the enhancement is implemented.

[BillyONeal]

These options aren't really expected to be "frontline user facing things" and haven't even really been "designed" -- if we were to drop the x- we would probably change the behavior to not require specifying them individually, and we're actively taking steps to make the scripts part not replaceable at all (because most of the scripts content are becoming ports).

As such I don't think extending the use of these settings and the potential backcompat pain it would cause is a good idea. When we've spent design effort here to define what the feature should be, rather than the quick and dirty workaround so that we can retarget our CI system off of the C: drive, it makes sense to give those things environment variables.

[Be-ing]

FWIW I don't even know what the scripts directory is. IIRC I opened this mostly because I want to specify the install root.

[BillyONeal]

At a bare minimum redirecting the installed tree makes sense. @Be-ing Are you OK with rewriting this issue as only affecting installed then? Then the fix is:

• Stabilize --x-install-root => --install-root. (This bikeshed needs to be painted)
• Add environment variable for the same. (This might need to start as an X_ variable though that seems unlikely)
• Remove the others from help text

[0xjairo]

how does one use these x- flags in manifest mode from CMake?

[dg0yt]

how does one use these x- flags in manifest mode from CMake?

You can pass specify additional vcpkg parameters in CMake variable `VCPKG_INSTALL_OPTIONS: https://github.com/microsoft/vcpkg/blob/master/docs/users/manifests.md#vcpkg_install_options

[0xjairo]

That worked, thanks. Cross referencing other discussion: https://github.com/microsoft/vcpkg/discussions/19147#discussioncomment-1438069