How to integrate this in a CMake project? about pybind11_protobuf HOT 13 OPEN

Would you be open to adding a CMakeLists.txt for this project? I can prepare a PR

In a nutshell: open yes, staffed no.

The main problem is that we're not set up to accept external PRs. The reasons are purely technical. It's a fairly big project to enable the workflow needed.

But, if you're ok doing things manually for now, the process would be:

• You create a PR as usual.
• I could import it more-or-less manually into the Google environment, tweak & submit internally.
• Then the automatic service will kick in to export the change here.

I believe this could work ok for adding cmake support (assuming there will mostly or even purely be additional files; it would probably be a lot less practical for core code changes).

Let's give it a shot and see how it goes?

from pybind11_protobuf.

Edit: after downloading the header and placing it where it can be found, I get an undefined reference to an absl object when importing:

❯ python -c 'import fastproto; print(fastproto.get_person())'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: /home/maxnoe/Projects/protobuf_pybind/build/fastproto.cpython-310-x86_64-linux-gnu.so: undefined symbol: _ZN4absl12lts_2021110213hash_internal15MixingHashState5kSeedE

from pybind11_protobuf.

Edit: I managed to make this work by linking against linking absl::hash absl::flat_hash_map), see the updated repo.

Would you be open to adding a CMakeLists.txt for this project? I can prepare a PR

from pybind11_protobuf.

Hi @maxnoe, I put together a cmake build for a project to provide bindings for some of the ignition robotics libraries. The pybind11_protobuf branch with the cmake support is here: https://github.com/srmainwaring/pybind11_protobuf/tree/feature/cmake, but it seems that you've got it sorted in the meanwhile.

I'd also be keen to see cmake support included in the repo.

from pybind11_protobuf.

@srmainwaring Thanks! This is looking good. I see that you only include the protobuf library for the one header I also mentioned above.

I opened this issue here, to get it included in the python package: protocolbuffers/protobuf#9464

If I understand it correctly, that header should be part of the python packge and probably some utility method to get it's location.

from pybind11_protobuf.

Yes, having the headers in a place that doesn't require bringing in protobuf directly would be good.

I used submodules to include the various dependencies, but that does present some problems (i.e. conflicts) when this package is included in larger projects, so it may be better to use cmake's find_package for everything. The approach may also depend on what platform your using (I use macOS with brew for package management). Using find_package does break the hermitic build that the Basel approach offers but from the standpoint of integrating with other third-party libraries that are already including a number of the same dependencies this might be an acceptable compromise.

I don't have a strong view either way, but please use any changes in my branch if they are helpful - and I'll be happy to help with testing.

from pybind11_protobuf.

A am a bit confused now. Why is this under the pybind organisation if this is still an internal google project?

from pybind11_protobuf.

from pybind11_protobuf.

Would you be open to adding a CMakeLists.txt for this project? I can prepare a PR

In a nutshell: open yes, staffed no.

The main problem is that we're not set up to accept external PRs. The reasons are purely technical. It's a fairly big project to enable the workflow needed.

But, if you're ok doing things manually for now, the process would be:

• You create a PR as usual.
• I could import it more-or-less manually into the Google environment, tweak & submit internally.
• Then the automatic service will kick in to export the change here.

I believe this could work ok for adding cmake support (assuming there will mostly or even purely be additional files; it would probably be a lot less practical for core code changes).

Let's give it a shot and see how it goes?

cc @joelynch

from pybind11_protobuf.

So it appears there's no hope for pybind11 due to protocol buffer support for python taking a drastic turn away from being able to support cmake and their new UPB thing?

from pybind11_protobuf.

So it appears there's no hope for pybind11 due to protocol buffer support for python taking a drastic turn away from being able to support cmake and their new UPB thing?

I don't understand this comment at all TBH.

Did you see that @srmainwaring contributed cmake support? Merged via #110 on Mar 9, 2023, fixes by @lopsided98 merged via #129 on Aug 25, 2023.

If that does not work for you, please provide exact details (ideally a reproducer).

from pybind11_protobuf.

@kyranf My understanding is that if you use pybind11 to create python bindings to C++ protobuf objects, you won't use the python protobuf module at all.
So them switching to upb shouldn't affect this here, correct?

from pybind11_protobuf.

So it appears there's no hope for pybind11 due to protocol buffer support for python taking a drastic turn away from being able to support cmake and their new UPB thing?

I don't understand this comment at all TBH.

Did you see that @srmainwaring contributed cmake support? Merged via #110 on Mar 9, 2023, fixes by @lopsided98 merged via #129 on Aug 25, 2023.

If that does not work for you, please provide exact details (ideally a reproducer).

if I take @srmainwaring 's gz-python project which uses pybind11 and for python to use the protobufs as a dependency, it cannot compile with cmake as it cannot find one of the headers. This is a known issue right now on that project.

srmainwaring/gz-python#24

from pybind11_protobuf.