On Thu, Sep 12, 2019 at 3:14 PM Antoine Pitrou <anto...@python.org> wrote: > > > Le 12/09/2019 à 20:14, Wes McKinney a écrit : > > hi folks, > > > > I wanted to share some concerns that I have about our current > > trajectory with regards to producing shared libraries from the Arrow > > build system. > > > > Currently, a comprehensive build produces many shared libraries: > > > > * libarrow > > * libarrow_dataset > > * libarrow_flight > > * libarrow_python > > * libgandiva > > * libparquet > > * libplasma > > Each library pulls its own set of non-trivial third-party dependencies. > For example, libarrow_flight includes gRPC, libcurl and OpenSSL as far > as I remember. > > Worse, libarrow_cuda depends on the NVidia CUDA libraries. That's a > *huge* dependency (and may also have runtime costs in addition to > installation / deployment annoyances). > > Some packagers may also want to distribute some sublibraries separately > (Linux distros especially tend to like having many small, focussed > shared libraries that they can distribute as separate, dependent > packages) - but that's not my business and I'll let them speak up ;-) >
It's a fair point. Another possibility is to be more Boost-like in the approach to the library structure. But there are costs involved with this, e.g. each Boost component that produces a shared library carries its own visiblity baggage https://github.com/boostorg/filesystem/blob/e268f557df657079be5ba4c19ab0d41ce66b6fb3/include/boost/filesystem/config.hpp My general point stands in any case, that we've encountered some rottenness w.r.t. cross-DLL symbol management and we need to confront the issues and decide how to deal with them. > So without deeper analysis I'm a bit worried about this proposal. > > Regards > > Antoine.
