-
Notifications
You must be signed in to change notification settings - Fork 374
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proto libraries in external/googleapis/
are always compiled
#8022
Comments
external/googleapis/
are always compiled and duplicatedexternal/googleapis/
are always compiled
We still want to clean this up, maybe now that we have CMake >= 3.10 we can fix this. |
A customer is asking for this. See the discussion in: #10174 |
Realistically we will not have time to work on this. Closing for now. |
We discussed this, and decided that building extra protos is in fact a bug. It is an unnecessary burden on customers who build with cmake and do not want to compile these extra protos. |
Here is what the changes for Googlers can see this before/after of a full install: BEFORE: https://paste.googleplex.com/6469566354948096 Also, I verified that if I install other libraries, the dialogflow protos are not installed. yay. I need to think about how we want to test this... Maybe we...
|
The proto libraries in
external/googleapis/
are always compiled (unless gRPC is completely disabled, but that is Okay).Most of them are small libraries with only one proto file in them, and many of them (things like "api.proto") are used by almost all libraries. Not particularly onerous, but there are a few (e.g.
google_cloud_cpp_cloud_texttospeech
,google_cloud_cpp_monitoring
) that are larger. We could move them togoogle/cloud/${service}
and compile them only when needed.We need to have a plan on how to deal with these larger libraries.
We should also consider merging all the smaller libraries into a single
.a
file. "One library per proto" makes no sense for the CMake build + install model, creates friction for customers, and (if we solve the many other problems) is very inconvenient for DLLs exports. We can be backwards compatible with a series of interface-only targets.The text was updated successfully, but these errors were encountered: