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
