The current libarrow_bundled_dependencies.a was created to address the problem of libarrow.a being "useless" (unable to be used to link with application code) if any dependencies were built by the Arrow build system (notably: this the case when using the default allocator jemalloc). I'm not sure who would be harmed by forcing use of conan or vcpkg to manage bundled dependencies (rather than having Arrow build them), but it would be good to have a clearer picture of what that might look like in the "before and after".
On Thu, Aug 4, 2022 at 2:45 AM Antoine Pitrou <anto...@python.org> wrote: > > > I would welcome trimming down our hand-written dependency bundling and > delegate most of the work to vcpkg or conan, but I don't know how usable > and flexible those alternatives are. Somehow more knowledgeable > (probably Kou or perhaps Krisztian?) should answer. > > (also note that using an external package manager can restrict our > freedom in pinning a particular version of a dependency, though that's > perhaps not a problem with most of them) > > Regards > > Antoine. > > > Le 03/08/2022 à 19:57, Will Jones a écrit : > > I was creating this ticket ARROW-17295 [1], but ended up unsure if this is > > something we'd like to maintain, so I thought I would bring it up for > > discussion. Essentially: should we expand the capabilities of our bundled > > dependency system? Or should we constrain the scope and point users that > > wish for more functionality toward package managers such as vcpkg and Conan? > > > > My understanding is that our bundled dependency system was created to fill > > the gaps where package managers failed to provide working builds or a > > recent enough version of a package. More recently, we added support for > > vcpkg and have started to use that in many of our CI and packaging builds > > [2]. And in the past few months, we have worked on adding support for Conan > > [3]. > > > > So my question is what is the future of Arrow C++'s bundled dependency > > system? Do we want: > > (a) To expand its functionality and encourage use by downstream projects > > (b) Keep as is, and consider it primarily for internal use > > (c) Move away from it in favor of using vcpkg or conan > > > > [1] https://issues.apache.org/jira/browse/ARROW-17295 > > [2] > > https://github.com/apache/arrow/blob/master/dev/tasks/python-wheels/github.osx.amd64.yml > > [3] https://issues.apache.org/jira/browse/ARROW-16089 > >
