How distribute exe tools like protobuf compiler?

[KindDragon]

vcpkg install return error:

The following EXEs were found in /bin and /debug/bin. EXEs are not valid distribution targets.

    D:/Work/vcpkg/packages/protobuf_x86-windows/bin/protoc.exe

but we need protoc.exe for using protobuf library

[ras0219-msft]

Packaging up EXEs is tricky, because when cross-compiling you really want to keep using the same protoc (host is x64-windows, let's say) even when you're targeting arm-uwp.

For now, I think the best approach will be to only install the runtime and have consumers download the pre-built binaries from google: https://github.com/google/protobuf/releases. This should be stable since it's the recommended mechanism for all non-C++ languages.

In the future, we need to figure out a solid mechanism for handling these sorts of tools+runtimes; ideally with a way for them to supply buildsystem integration as well. We very much don't want programs to be pulling their DLLs directly from inside installed\x64-windows\bin, because then upgrading the DLLs is tricky. Perhaps we should always static link tools and put them in their own special folder, like installed\x64-windows\tools?

[ghost]

Yes, building tools from source would be preferable, since then they are always in sync with their library components. installed\x64-windows\tools sounds good, if there is an easy way for dependent projects to refer to these programs from VS and CMake.

[KindDragon]

For now, I think the best approach will be to only install the runtime and have consumers download the pre-built binaries from google: https://github.com/google/protobuf/releases. This should be stable since it's the recommended mechanism for all non-C++ languages.

How then compile grpc that depending on protobuf and protoc? Can vcpkg_download_distfile be used for that?

Perhaps we should always static link tools and put them in their own special folder, like installed\x64-windows\tools?

I think that copying with dependent dll's to installed\x64-windows\tools is fine too

[ras0219-msft]

For similar tools like perl and nasm, we have vcpkg_find_acquire_program: https://github.com/Microsoft/vcpkg/blob/master/scripts/cmake/vcpkg_find_acquire_program.cmake. This allow users to bring their own version (with all the goodness and badness that implies). Needing to add every tool to this central file doesn't scale very well, but for now since we only have a handful of tools it isn't a problem.

I can see arguments for using either vcpkg_download_distfile or vcpkg_find_acquire_program; both should work.

[KindDragon]

BTW protobuf cmake contain function PROTOBUF_GENERATE_CPP that many libs use. So in this situation we need patch this cmake

[ras0219-msft]

The approach that appears to work best for protobuf is to download the officially built (i386) compiler for the given source release. This removes the need for a complicated dual build -- one against the host and one against the target. It also should be just as robust as building protoc from source since using the prebuilt compiler is the recommended consumption method for other languages.

It was also quite straightforward to patch the protobuf-targets-*.cmake files to point at the installed\<triplet>\tools directory instead of bin.

See #88 for what this looks like in a portfile.

[KindDragon]

Thank you