Open StefanBruens opened 2 months ago
Tagging @srmainwaring who contributed the cmake support.
Could/should we adopt the or-tools patch here?
It all depends on the architecture you want to have.
Most of the code could just be moved to header-only. Having the implementation in a static library does not provide any benefit, but has several drawbacks:
The big outlier is the GlobalState
singleton. That does not fit "header-only". The question is, is this singleton actually required to be a singleton, or is this just an optimization to cache the protocol definitions. I am tempted to vote for the latter to be the case here - otherwise several python modules using pybind11_protobuf (possibly different versions) would not actually work.
Note, having the implementation in a static library get rids of the the symbol visibility problem, but does not solve the ABI problem the limited visibility is meant to solve. The static library may be compiled with one pybind11 version, but the module using it may use a different pybind11 version.
Most of the code could just be moved to header-only.
I think that's very unlikely to happen. (Just wanted to let you know; very long background omitted.)
Most of the code could just be moved to header-only.
I think that's very unlikely to happen. (Just wanted to let you know; very long background omitted.)
Care to elaborate? As far as I can see, the static library only has downsides.
Nothing nice, I'm afraid, tbh: currently unclear ownership and governance, "best effort" only (fancy for: no actual staffing). — Hopefully some things will improve in the next few months.
Nothing nice, I'm afraid, tbh: currently unclear ownership and governance, "best effort" only (fancy for: no actual staffing). — Hopefully some things will improve in the next few months.
Ah, so not a policy decision, but "just" lack of time ...
Both native and wrapped proto_casters use several functions from
proto_cast_util.cc
. Unfortunately, most of these functions are not actually usable, as the pybind11 defaulthidden
visibility is propagated to these functions.This can be verified by analyzing the generated object file:
All method using a parameter from the
pybind11::
namespace becomes "hidden", and when linking the object file into the shared library the HIDDEN symbols are omitted from the symbol table.See https://pybind11.readthedocs.io/en/stable/faq.html#someclass-declared-with-greater-visibility-than-the-type-of-its-field-someclass-member-wattributes
google-or-tools
e.g. patches the pybind11_protobuf build to create a static library (which is not affected by symbol visibility) to work around this problem:https://github.com/google/or-tools/blob/2384738a951561bf905f3435651310841c309b4c/patches/pybind11_protobuf.patch#L32