-
Notifications
You must be signed in to change notification settings - Fork 364
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
Add Abseil dep in cmake and bazel #2309
Comments
We should try to find some tests or integration tests that could benefit from using Abseil. That way we can introduce the dependency without complicating the installation instructions for existing users. |
SGTM. |
I have this partially (?) working (WIP branch). The easiest solution is to just use The current solution requires manually listing all the targets (and I've seen this used in other projects like TensorFlow for example), like so: # Create imported target absl::config
add_library(absl::config INTERFACE IMPORTED)
set_library_properties_for_external_project(absl::config absl_config
HEADER_ONLY)
add_dependencies(absl::config abseil_project)
# ...and so on... I have managed to get A third solution to automatically get all of the imports is to use a secondary external project; install abseil first to get the I'm sure there is an easier way that I'm missing. |
I think we should wait for Abseil for a couple of reasons: (a) they are working on support for shared objects, which they currently do not have (?), and we use in at least some platforms, and (b) it would be easier to add Abseil when all the dependencies are found via |
I believe it should be possible for us to take a dep on Abseil now. Indeed, newer versions of gRPC will require it. Taking a dep on Abseil should be no problem for bazel users, because as long as they call our However, for CMake users, is taking a dep on Abseil will require that either the customer use our super build, which will automatically fetch Abseil, or they must install Abseil themselves. It's no problem to update our packaging instructions, etc to install Abseil. Q: How do we message to our users that a new release of the library now requires a new dep? Is a simple message in the release notes good enough? Q: Will there be any changes needed to our vcpkg? I'm guessing that after our next release, our next vpkg definition will need to list Abseil as a dep, then it should Just Work? Q: Is there anything else to consider before I give us a dep on Abseil? |
I agree.
Correct.
I think so.
It is already working.
Testing with shared libraries and with static libraries for Linux is already in the matrix. For Windows, the quickstart builds test with DLLs and static libraries but we do not have regular builds that test with both. Since DLLs were a concern for Abseil maybe we should test early instead of waiting a full release cycle. |
I'm not sure I follow what you mean here. What do you mean by testing early rather than waiting a release cycle? FTR, I have a draft PR that's getting fairly close to working #4087. I'm wondering what else we should do before we land that PR. Do we need to add another CI build? |
Well, what I was thinking: the only DLL build we have is OTOH, that has been building against Abseil for a while now.
It might be a good idea to have a CI build that compiles the current code against DLLs. I do not think we should gate your PR for that. |
Ahh, I see. Makes sense. I filed #4090 to track that specific issue so we don't need to block the adoption of Abseil. |
Fixes: #2309 Adds a dep on Abseil. Uses absl::make_unique in one test in Spanner just to show that the Abseil dep is working in all the builds.
Now that Abseil is close to (or done?) adding a cmake install target (abseil/abseil-cpp#111), we may want to consider adding Abseil as a dep and using it where appropriate. I think a good first step for this particular issue would be to:
Add Abseil as a dep to our cmake and bazel builds.
Change some small piece of our internal code to use Abseil. This will demonstrate that the build deps adding in step 1 work in both cmake and build.
It's important that we don't initially change anything that we export in a public interface until we explicitly decide to use Abseil in interfaces. And example of a change for step 2 that might make sense is changing calls to our internal make_unique -> absl::make_unique. That touches about 275 locations, so that may be a bit big. Another idea might be changing the implementation of
internal::ParseRfc3339
andinternal::FormatRfc3339
to be implemented in terms of the absl/time types and functions. This would be a slightly more involved change, but it would only touch a couple files.Maybe there are smaller things we could change to satisfy step 2 above also. Feel free to suggest something. The goal is to test that the build deps work correctly.
The text was updated successfully, but these errors were encountered: