Add VCPKG_SCRIPTS_DIR and VCPKG_TOOLS_DIR to the CMake command call

[Neumann-A]

To make stuff mentioned in #1315 (comment) not magically (and maybe even wrongly) calculate those paths.

[Neumann-A]

Should this be just SCRIPTS since it is already defined in ports.cmake ?

[BillyONeal]

That makes sense to me

[BillyONeal]

Alternately I think --x-scripts-root should die because there is no safe way for it to be used at present.

[Neumann-A]

Alternately I think --x-scripts-root should die because there is no safe way for it to be used at present.

Please explain

[BillyONeal]

Alternately I think --x-scripts-root should die because there is no safe way for it to be used at present.

Please explain

The only acceptable content for the scripts tree is the same content that matches the copy of vcpkg, the tool, itself. There is no meaning to the user trying to replace where that is, the only reason the switch exists has long gone.

[Neumann-A]

Alternately I think --x-scripts-root should die because there is no safe way for it to be used at present.

Please explain

The only acceptable content for the scripts tree is the same content that matches the copy of vcpkg, the tool, itself.

I am still missing the why explanation here. So I still need a sentence which starts something like "because otherwise ...." or something logically similar.

Whatever the decision about the cli switch this PR just passes down internal path knowledge. If this is scripts dir or the dir of the cmake entry point (ports.cmake) with the scripts subfolder added doesnt really matter.

[BillyONeal]

I am still missing the why explanation here. So I still need a sentence which starts something like "because otherwise ...." or something logically similar.

There isn't going to be a 'because otherwise'. We reserve the right to make coordinated tool and scripts tree changes, so the set of potential issues is undefined.

Whatever the decision about the cli switch this PR just passes down internal path knowledge. If this is scripts dir or the dir of the cmake entry point (ports.cmake) with the scripts subfolder added doesnt really matter.

In general I'm happy with not calculating something multiple times; I just think the right fix here is to delete the scripts dir setting entirely. It does not exist to do practical things, it exists because once upon a time we blindly added knobs for "all the directories" even ones that would be meaningless to touch.

local_variables.emplace_back("VCPKG_TOOLS_DIR", paths.tools);

This proposed VCPKG_TOOLS_DIR and the one in scripts\buildsystems\vcpkg.cmake are totally different; the one in VcpkgPaths refers to %DOWNLOADS%\tools, while the one in vcpkg.cmake refers to in the installed tree.

[Neumann-A]

This proposed VCPKG_TOOLS_DIR and the one in scripts\buildsystems\vcpkg.cmake are totally different; the one in VcpkgPaths refers to %DOWNLOADS%\tools, while the one in vcpkg.cmake refers to in the installed tree.

There is no VCPKG_TOOLS_DIR in vcpkg.cmake there is only a Z_VCPKG_TOOLS_DIR which is not related to this one. (and it is correct to point into downloads; maybe rename vcpkg.cmake into Z_VCPKG_INSTALLED_TOOLS_DIR to be more explicit) I could also rename this one to VCPKG_DOWNLOADED_TOOLS_DIR (I really don't care about the naming)

There isn't going to be a 'because otherwise'. We reserve the right to make coordinated tool and scripts tree changes, so the set of potential issues is undefined.

I don't think you can do that considering that ports.cmake defines:

set(SCRIPTS "${CMAKE_CURRENT_LIST_DIR}" CACHE PATH "Location to stored scripts")
list(APPEND CMAKE_MODULE_PATH "${SCRIPTS}/cmake")

which makes the script dir an (indirectly) official variable and changing that would be a breaking change for others? I don't mind the scripts variable too much IF the triplet file always gets to to see the same set of predefined functions. Currently the triplet is included in two different ways once from ports.cmake with everything defined and once with nothing when calculating the settings.

[BillyONeal]

I don't think you can do that considering that ports.cmake defines:

That we have a variable pointing there does not mean that we support what happens if someone tries to change it to something else. If that had been added after we added the X- and Z- conventions that would have a Z-.

Given that we are already setting the variable I can see the argument to calculate it in one place and not all over the place but there is no practical feature in trying to separate the scripts tree from the tool.

As for VCPKG_TOOLS_DIR I don't see a reason to add this, particularly after microsoft/vcpkg#43309