Comments (7)
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
?
from vcpkg.
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.
from vcpkg.
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
from vcpkg.
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.
from vcpkg.
BTW protobuf cmake contain function PROTOBUF_GENERATE_CPP
that many libs use. So in this situation we need patch this cmake
from vcpkg.
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.
from vcpkg.
Thank you
from vcpkg.
Related Issues (20)
- [zlib] Build error on x64-windows HOT 1
- [glad] update to 2.0.6 HOT 1
- [boost-container] Build error on wasm32-emscripten
- [cppgraphqlgen] Build error on x64-linux HOT 1
- [gperf] Build error on x64-windows HOT 1
- [qtwebengine] Build error on x64-windows HOT 2
- [boost-cobalt] Build error on x64-linux HOT 5
- [boost-container] build failure on Windows (missing boost-static-assert dependency) HOT 1
- [vcpkg-tool] vcpkg should cache binaries downloaded from AWS locally instead of downloading them every time
- vcpkg ignoring default-features: false in custom overlay HOT 2
- vcpkg_from_gitlab fails to download but project exists / URL is correct HOT 2
- [osg] Build failure on x64-windows HOT 7
- [qtinterfaceframework] Build error on x64-linux
- [zydis] update to 4.1.0
- [zycore] update to 1.5.0
- messy code output in Visual Studio 2022 while building HOT 4
- sqlite3[dbstat] doesn't enable dbstat actually. HOT 1
- x-update-baseline does not respect reference (git branch) HOT 2
- [crashpad] Build error on x64-linux
- [rest-rpc] update to 0.12
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vcpkg.