Add cc_static_library for non-bazel projects #281
Conversation
| If you are not using Bazel, you can instead build a standalone version | ||
| of TCMalloc that you can vendor in your project. Before doing so you | ||
| should still run the tests, as described above, to make sure the | ||
| vendored library will work in your environment. Then build the |
There was a problem hiding this comment.
Suppose I also link against Abseil, but I build it with CMake, in addition to the TCMalloc library provided by this target.
- I assume I absolutely, positively have to use the same version of Abseil?
- What symbols end up exported from the cc_static_library?
- Anything else someone should be aware of?
There was a problem hiding this comment.
great callouts 🙏🏻
- added a note about this
- a whole lot more than is considered public API but I believe to fix that we'd have to flip the fvisibility default, or potentially produce a relocatable object via an allowlist of symbols. I don't think there's a difference between the public symbols included in this archive vs the combined public symbols in all the static libs that would make up tcmalloc in a normal bazel build
- i didn't do anything with headers in this case, so i guess if users actually wanted to access some public API, we'd have to handle that separately, but I figured that shouldn't be an issue for most cases
There was a problem hiding this comment.
Is there a convenient way of hermetically testing this? I poked Bazel briefly by adding this to variants.bzl's list, but it didn't like being specified as the malloc attribute, nor does it really know what to do with it as a dep.
I'm trying to figure out which is the lesser evil of symbol visibility versus potential ODR issues.
- Symbol visibility probably means making
MallocExtension& friends not work, because quite a few of those contain Abseil types. In practice, those ABIs don't change much; but this isn't guaranteed by Abseil either. - No symbol visibility means exporting a lot of other stuff, and potentially running afoul of ODR issues in subtle ways if/when it does happen.
There was a problem hiding this comment.
I've pushed a test skeleton pulling the example from the quickstart, they have to be manual unless you're ok with us flipping --experimental_cc_static_library in the .bazelrc.
What do you think we should throw in there instead of those default contents?
Bazel 7.4.x+ have a new `cc_static_library` rule that creates a redistributable static library from a set of deps. This allows us to create a standalone version of tcmalloc that users can easily pull into non-bazel projects. This should lower the friction for cmake users to use tcmalloc.
keith
force-pushed
the
ks/add-cc_static_library-for-non-bazel-projects
branch
from
24b1691 to
3fc9406
Compare
|
I flipped the default of the experimental feature since it seems like I have traction flipping that upstream too, this way we can run those tests always too |
Bazel 7.4.x+ have a new
cc_static_libraryrule that creates aredistributable static library from a set of deps. This allows us to
create a standalone version of tcmalloc that users can easily pull into
non-bazel projects.
This should lower the friction for cmake users to use tcmalloc.