Building 0.7.1 on my OS X 10.13 machine, I instrumented the build and see that both stages of the compiling (the internal libdatrie and the python glue code) are actually using the libdatrie headers installed elsewhere on my system. But then linking the glue code uses the internal liblibdatrie.a. Why does this python package include its own copy of libdatrie at all instead of using it externally installed on the system? Seems like extra effort to keep it in sync (and patch), and now we see there is a need to hack on setuputils's flag passing problem. See for example https://salsa.debian.org/python-team/modules/python-datrie/blob/master/debian/patches/0002-Don-t-use-bundled-libdatrie.patch
Building 0.7.1 on my OS X 10.13 machine, I instrumented the build and see that both stages of the compiling (the internal libdatrie and the python glue code) are actually using the libdatrie headers installed elsewhere on my system. But then linking the glue code uses the internal liblibdatrie.a. Why does this python package include its own copy of libdatrie at all instead of using it externally installed on the system? Seems like extra effort to keep it in sync (and patch), and now we see there is a need to hack on setuputils's flag passing problem. See for example https://salsa.debian.org/python-team/modules/python-datrie/blob/master/debian/patches/0002-Don-t-use-bundled-libdatrie.patch