I agree with Andrew.  If we are going be serious about supporting
additional architectures we should merge these changes along with
changes adding them to CI.

On November 12, 2020, Andrew Lamb <al...@influxdata.com> wrote:
> In general I think expanding support for additional architectures is a
> good
> idea. The list of possible features and support you describe is pretty
> substantial, and I suggest we are careful about taking on too much too
> soon.
>
> In terms of what to support, I would personally recommend waiting for
> someone who wants to use Rust / arrow on a specific platform (and thus
> has
> the time to help us test). Without user input I don't have any sense
> of
> which platforms you list below are the most important
>
> If we truly want to support a new platform, I think it is important to
> actually test on machines of the target architectures (not just cross
> compile for them). It is not clear to me how much additional effort
> setting
> up such CI will be, or what resources we have available to test.
>
> Andrew
>
> On Thu, Nov 12, 2020 at 6:42 AM vertexclique vertexclique <
> vertexcli...@gmail.com> wrote:
>
> > In addition to the previous e-mail there are some changes at
> companies like
> > Apple:
> > Next-generation will ship will Aarch64 as you know. Since my local
> test
> > showed that we can build on:
> > * aarch64-unknown-linux-gnu
> > But we need sysroot image for:
> > * aarch64-apple-darwin
> >
> > Aarch64 on apple is another topic we might want to visit later. But
> I am
> > %99 sure that it will work with the correct sysroot image and
> toolchain.
> > Because it is working on Linux gnu build.
> >
> > Best,
> > Mahmut
> >
> > vertexclique vertexclique <vertexcli...@gmail.com>, 12 Kas 2020 Per,
> 12:29
> > tarihinde şunu yazdı:
> >
> > > Hi Team;
> > >
> > > There are 3 topics fall under this:
> > > * no_std compatibility
> > > * endianness compatibility
> > > * target datapath size (32-bit/64-bit, rust naming
> target_pointer_width)
> > >
> > > So after the sync call yesterday, Micah said that there were
> efforts on
> > > that for some time at Java, C++ side. That's nice. Currently, most
> of our
> > > tests are passing in big-endian at Rust implementation (synched
> with
> > Jorge
> > > and Neville yesterday, told them). We need to tweak some things a
> little
> > > bit and then we can run on any os with the decent scheduler. Apart
> from
> > > that, it would be also nice that some of the Arrow Rust committers
> push
> > > WASM and no_std implementation together. I am very fond of no_std
> > > implementation and I would like to contribute on that side.
> > >
> > > CI process:
> > > No need to worry, docker helps to run any tier 1 triple with
> nearly half
> > > of tier 2 triple with the help of cross. A couple of things at
> that side
> > > would be:
> > > 1- Should we add ARMv7 and ARMv6 CI in this PR:
> > > https://github.com/apache/arrow/pull/8609
> > > 2- Which triples do you want to support? My suggestion follows:
> > > After the aforementioned PR #8609, these will be supported:
> > > * arm-linux-androideabi
> > > * arm-unknown-linux-gnueabi
> > > * arm-unknown-linux-gnueabihf
> > > * arm-unknown-linux-musleabi
> > > * arm-unknown-linux-musleabihf
> > > * armv7-linux-androideabi
> > > * armv7-unknown-linux-gnueabi
> > > * armv7-unknown-linux-gnueabihf
> > > * armv7-unknown-linux-musleabi
> > > * armv7-unknown-linux-musleabihf
> > >
> > > (thumbv7neon-linux-androideabi and thumbv7neon-unknown-linux-
> gnueabihf
> > needs
> > > adjustments for linkers. Not sure about them right away)
> > >
> > > After big-endian support I suggest building on OS first:
> > > * mips-unknown-linux-gnu
> > > * mips-unknown-linux-musl
> > >
> > > Then we arrive at the final destination no_std with:
> > > * thumbv6m-none-eabi
> > > * thumbv7em-none-eabi
> > > * thumbv7em-none-eabihf
> > > * thumbv7m-none-eabi
> > > * armv7a-none-eabi
> > > * armv7r-none-eabi
> > > * armv7r-none-eabihf
> > >
> > > And optionally:
> > > * armebv7r-none-eabi
> > > * armebv7r-none-eabihf
> > >
> > > Best,
> > > Mahmut
> > >
> > >
> > >
> >

Reply via email to