Just to be clear: this is not part of the 0.15 release discussion, right?
On Thu, Sep 12, 2019 at 1:29 PM Wes McKinney <wesmck...@gmail.com> wrote: > > 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.
