Closed agarny closed 1 week ago
Looking at this I can't help but think that we should restrict what you build with a static libCellML library.
Looking at this I can't help but think that we should restrict what you build with a static libCellML library.
- Does it make sense to build coverage with a static library?
I had a quick look and it seems like it might not be possible in fact, despite compiling it with the correct flags for gcov
and llvm-cov
. So, I would just prevent gcov
and llvm-cov
support when building a static library.
- Does it make sense to build the Python bindings with a static library?
Can't comment on that one. I use pybind11
for Python bindings in libOpenCOR, so it's done differently.
I have had a look at this and I think we might want to offer a configurable option for building a static library with or without position independent code. For some situations it is better and even required to build static libraries without position independent code and for others like building on 64bit Ubuntu you must build with it if you want to link it into something dynamic.
I am not sure whether we should worry about that. If someone wants a static version of libCellML for use in a shared library then it looks like they could pass -DCMAKE_POSITION_INDEPENDENT_CODE=ON
or -DCMAKE_C_FLAGS=-fPIC
to CMake (source: https://github.com/signalapp/libsignal-protocol-c/issues/50). So, if anything, I would document that rather than making it part of our CMake configuration process.
If you set
BUILD_SHARED
toOFF
then to build libCellML on Ubuntu 20.04 LTS will result in the following output:On macOS: