Yes, I don't think we should go the full way of separating Arrow in
micro-components. The IO and IPC layer aren't heavyweight. We should
simply address the most often-quoted annoyances.
Regards
Antoine.
Le 20/09/2019 à 17:41, Wes McKinney a écrit :
> Implementing the format fully requires
Implementing the format fully requires memory management and IO
interfaces (i.e. arrow/io/{file.h, interfaces.h, memory.h}). So those
parts are not separable.
On Fri, Sep 20, 2019 at 10:36 AM Neal Richardson
wrote:
>
> I wonder if having a core "format" C++ library, which the io, compute,
> etc.
I wonder if having a core "format" C++ library, which the io, compute,
etc. library/libraries would depend on, is a natural step.
Particularly since we're coming up on 1.0 and the format is being
declared stable.
Neal
On Fri, Sep 20, 2019 at 8:28 AM Wes McKinney wrote:
>
> We would have to be
We would have to be even more careful about managing symbol exports.
Third party projects would need to link more libraries in their
applications (not unlike the way that Boost works now -- I suppose
that Boost is the closest analogue to what we're going for)
On Fri, Sep 20, 2019 at 2:30 AM Micah
>
> We could indeed split up libarrow into more shared libraries. This
> would mean accepting a lot more maintenance effort though, on a team
> that is already overburdened. I'm not too keen on that in the short
> term.
Something for longer term to think about. What are you seeing as the added
hi Micah,
On Thu, Sep 19, 2019 at 12:41 AM Micah Kornfield wrote:
>
> >
> > * Should optional components be "opt in", "out out", or a mix?
> > Currently it's a mix, and that's confusing for people. I think we
> > should make them all "opt in".
>
> Agreed they should all be opt in by default. I
>
> * Should optional components be "opt in", "out out", or a mix?
> Currently it's a mix, and that's confusing for people. I think we
> should make them all "opt in".
Agreed they should all be opt in by default. I think active developer are
quite adept at flipping the appropriate CMake flags.
To be clear I think we should make these changes right after 0.15.0 is
released so we aren't playing whackamole with our packaging scripts.
I'm happy to take the lead on the work...
On Wed, Sep 18, 2019 at 9:54 AM Antoine Pitrou wrote:
>
> On Wed, 18 Sep 2019 09:46:54 -0500
> Wes McKinney
I think these are both interesting areas to explore further. I'd like
to focus on the couple of immediate items I think we should address
* Should optional components be "opt in", "out out", or a mix?
Currently it's a mix, and that's confusing for people. I think we
should make them all "opt in".
Hello Micah,
I don't think we have explored using bazel yet. I would see it as a possible
modular alternative but as you mention it will be a lot of work and we would
probably need a mentor who is familiar with bazel, otherwise we probably end up
spending too much time on this and get a
It has come up in the past, but I wonder if exploring Bazel as a build
system with its a very explicit dependency graph might help (I'm not sure
if something similar is available in CMake).
This is also a lot of work, but could also potentially benefit the
developer experience because we can make
Hello,
I can think of two other alternatives that make it more visible what Arrow core
is and what are the optional components:
* Error out when no component is selected instead of building just the core
Arrow. Here we could add an explanative message that list all components and
for each
12 matches
Mail list logo
