-from-a-public-or-private-server
>
> I think that building all dependencies on each
> users/developers' machine should be avoided as much as
> possible.
>
>
> Thanks,
> --
> kou
>
> In
> "[C++] Purpose of C++ bundled dependencies" on Wed, 3 Aug 2022 10:57:48
>
-a-public-or-private-server
I think that building all dependencies on each
users/developers' machine should be avoided as much as
possible.
Thanks,
--
kou
In
"[C++] Purpose of C++ bundled dependencies" on Wed, 3 Aug 2022 10:57:48 -0700,
Will Jones wrote:
> I was creating t
I don't think I made it clear in my original email, but I don't wish to
propose a new direction; rather, I want to understand the direction we are
currently heading.
As we've added vcpkg and conan support, is the intention we would replace
our bespoke dependency management system? Or take on
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
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
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
