[GRPC] Strange triplet behaviour

[jdx-john]

I use a custom triplet based on x86/x64-windows-static-md triplet:

set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE static)
set(VCPKG_PLATFORM_TOOLSET "v142")
set(VCPKG_DEP_INFO_OVERRIDE_VARS "v142")
set(VCPKG_BUILD_TYPE release)

I have binary caching finally working but noticed GRPC was not using cached binaries, but rebuilding from source:

Starting package 364/381: grpc:x64-windows
Building package grpc[codegen,core]:x64-windows...
-- Note: grpc only supports static library linkage. Building static library.
-- Downloading https://github.com/grpc/grpc/archive/44c40ac23023b7b3dd82744372c06817cc203898.tar.gz -> grpc-grpc-44c40ac23023b7b3dd82744372c06817cc203898.tar.gz...
-- Extracting source C:/vcpkg2019/downloads/grpc-grpc-44c40ac23023b7b3dd82744372c06817cc203898.tar.gz
-- Applying patch 00001-fix-uwp.patch
-- Applying patch 00002-static-linking-in-linux.patch
-- Applying patch 00003-undef-base64-macro.patch
-- Applying patch 00004-link-gdi32-on-windows.patch
-- Applying patch 00005-fix-uwp-error.patch
-- Applying patch 00009-use-system-upb.patch
-- Applying patch 00010-add-feature-absl-sync.patch
-- Applying patch 00011-fix-csharp_plugin.patch
-- Applying patch snprintf.patch
-- Applying patch 00012-fix-use-cxx17.patch
-- Applying patch 00013-build-upbdefs.patch
-- Applying patch 00014-pkgconfig-upbdefs.patch
-- Using source at C:/vcpkg2019/buildtrees/grpc/src/17cc203898-d61717d122.clean
-- Configuring x64-windows
CMake Warning at scripts/cmake/vcpkg_configure_cmake.cmake:421 (message):
The following variables are not used in CMakeLists.txt:

  gRPC_GFLAGS_PROVIDER
  gRPC_INSTALL_CSHARP_EXT

Please recheck them and remove the unnecessary options from the
vcpkg_configure_cmake call.

If these options should still be passed for whatever reason, please use the
MAYBE_UNUSED_VARIABLES argument.
Call Stack (most recent call first):
ports/grpc/portfile.cmake:46 (vcpkg_configure_cmake)
scripts/ports.cmake:141 (include)

-- Building x64-windows-dbg

Apart from rebuilding, my custom triplet also chooses to only build release which is now being ignored and causing the build to take a lot longer as it builds debug too. I am not really sure why it is trying to build grpc:x64-windows rather than my custom triplet.

Actually I see later on, it does build grpc[core]:x64-my-triplet whereas for x64-windows it builds grpc[codegen,core]:x64-windows - codegen is added (I don't specify that in my scripts).

Does that mean something I build has a dependency on grpc[codegen] but is choosing to build it as x64-windows for some reason? Wouldn't dependencies be built using same triplet normally?
Can I easily find out who has this dependency to figure out if it's a bug? This has caused installing on a dev-box to take 30+ minutes instead of about 2, because every other package is restored from cache but grpc is being built multiple times!

[dg0yt]

grpc itself has a host dependency on grpc[codegen]. So unless the target triplet matches the host triplet, you will see another build.
This can be seen grpc's vcpkg.json.

[jdx-john]

I'm not quite I sure understand how a package can have a dependency on its own feature but I will take your word for that!

If I explicitly install grpc[codegen] with my custom triplet, will it still want to build x64-windows as a host triplet?

And are host triplets excluded from binary caching? It builds grpc[codegen]:x64-windows (release and debug) as it cannot find a cached version, then when it gets to build with my triplet it rebuilds that from source too, even though all my other packages are cached. I see mention of sources being cleaned and wonder if that's why.

GRPC is seemingly a large library that is slow to build, and it's partly negating the point of using binary caching. Is there anything I can do or is it a special case?

[dg0yt]

IIRC these changes to grpc were done only recently, and before that there was a lot stuff broken in one way or another. It should be easy to find the issues, pull requests, or check git log -- ports/grpc.

vcpkg tries to separate stuff which runs on the target from stuff which runs on the build machine (host). In the case of grpc, it is only the codegen feature which must run on the host. If you know that target binaries run on the host, you can set the host triplet to match the target triplet. (This is what I do for mingw, in absence of a MSVC installation.)

Once the binaries are in the cache, they should be reused in following installations. This works flawlessly in vcpkg's CI. However, changes can be triggered with each git pull, in particular from changes to central cmake scripts.

The user community couldn't yet convince the maintainers that there is a need for release-only triplets, but at least fixes are accepted. Perhaps the case of host tools should be stressed an extra argument.

[jdx-john]

Thanks @dg0yt that's interesting. I have previously tried to avoid doing anything with host triplets for fear of messing things up.

However, it doesn't sounds like this should stop binary-cache working? Once I got things set up it did work very smoothly, except grpc. It didn't find a cache for either the host triplet or my custom triplet and I wondered if one was a knock-on effect of the other even though in theory each triplet has a distinct build-tree.
For instance if I am building using install grpc:my-triplet --binarysource=clear --binarysource=files,<path><rw> and that causes grpc:x64-windows to be built, will my cache settings be applied? It just seems too much a coincidence this is the only package where caching didn't work.

I checked and the triplet_abi was identical for grpc:x64-windows on both machines, but it still didn't get picked up from the binary cache... the other ~375 packages all did!

[dg0yt]

The "triplet_abi" is just one item in the abi info.
For the actual info cf.
buildtrees/<PORT>/<TRIPLET>.vcpkg_abi_info.txt
For reference, cf.
https://github.com/microsoft/vcpkg/blob/master/docs/users/binarycaching.md#implementation-notes-internal-details-subject-to-change-without-notice

[jdx-john]

I looked at the full abi file and I could see one change only, in the has for "abseil" (presumably a dependency). I think this was the very first thing built when I was trying to get caching working so it may be I somehow have a 'stale' copy before I fixed issues.

Oh for a rebuild option or the ability for vckg to notice when things change. It does all these hashes for cache use but if you change anything that would modify those caches it doesn't detect this and you can easily end up with a mish-mash. I suppose the mindset is to treat /vcpkg as disposable so anytime you change something you start over but it would be nice if it caught these things and warned you.

Anyway I'll clean my dev box and try again.

BTW is buildtrees/<PORT>/<TRIPLET>.vcpkg_abi_info.txt the same as packages/<port><triplet>/share/<port>/vcpkg_abi_info.txt i.e. is it just copied from one to the other during installation?

[jdx-john]

One other question, is there any benefit to building host triplets as both debug and release? I was amazed to find my vcpkg directory was >50Gb, is anyone realistically going to debug vcpkg while using it?

[dg0yt]

One other question, is there any benefit to building host triplets as both debug and release? I was amazed to find my vcpkg directory was >50Gb, is anyone realistically going to debug vcpkg while using it?

Don't ask me. I think it is a Visual Studio convenience thing. With a Linux background, it is just strange. In particular, statically linked tools eat tons of space, easily outweighting the benefit of shared include and data: #19189 (comment)

[JackBoosY]

@jdx-john You can delete the buildtrees folder and packages folder safety.