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 > > > > > > >
