Generating a shared library for the C implementation (and using that to build pycatch22 etc.)

[sanjayankur31]

Hello!

We package and maintain catch22 for Fedora Linux. Now that pycatch22 has been split into its own repo and bundles the C sources, we were wondering if:

• it would make sense to compile the C sources from here and provide catch22 as a shared library (libcatch22.so.0 types on Linux)
• use the shared library to link against when building pycatch22 etc.

The advantage of this is that we won't need to bundle catch22 in pycatch22, and that catch22 is provided as a library for people using C to use.

@musicinmybrain has created a pull request that generates the shared library (by adding a Makefile and so on) here. The main question here, as you'll see from that pull request, is whether you (upstream) intend to provide it as a C library, and if you do, would you be committing to ABI/shared object versioning etc. to notify users of changes and so on?

Link to the libtool documentation on versioning: https://www.gnu.org/software/libtool/manual/html_node/Versioning.html#Versioning

[benfulcher]

Thanks for the input and interest in the package. Yes, we thought it was cleaner to separate out the R, python, and Julia wrappers into their own repos. We are not proficient in managing shared libraries, and for use in python are supporting installation as pycatch22 via pip.
If I understand correctly, there is elegance in the shared library solution in maintaining the C in a single place, but given we are not proficient in managing it and don't anticipate changes to it, were planning to go with the less elegant solution [in the case of any change being required: manually propagating (or using git submodule) any updates in the C source to the other (wrapper) packages for R, python, and Julia…], which allows the wrappers, like pycatch22, Rcatch22, and Catch22.jl, to work as standalone packages.

[sanjayankur31]

Thanks @benfulcher , that makes sense. We'll see what the best way of doing this downstream is. We tend to avoid bundling but in this case since you are the devs for all the tools that consume the C code, that takes away some of our concerns related to bundling (it's much more of an issue when lots of other developers start to bundle code and not keep it up to date with bugfixes etc.).

I'll close this ticket now. Thanks again.

[benfulcher]

Ok thanks @sanjayankur31 — appreciate your thoughtful input! Maybe someone will come along with a stronger computational background at some point… Hope all's going well with Fedora Linux.