Replies: 3 comments 7 replies
-
|
Linux ARM 32bit would be useful for building and deploying apps that run on a Raspberry PI. While it is not the most powerful platform it is an easy way to have a small cluster at home for testing purposes. Raspberry PI have gotten experimental support for 64bit, but most people still run 32bit since it have better stability. |
Beta Was this translation helpful? Give feedback.
-
|
Are you presently using Turborepo on a raspberry pi for builds? My general estimation is that it is primarily used as a deploy target. In other words, the build that uses Turborepo would not be run on it. Instead, the output would be sent to it. |
Beta Was this translation helpful? Give feedback.
-
|
I'm both building stuff on and running stuff on Raspberry PI's from time to time. To deploy stuff to a Raspberry PI in a Docker container I also use |
Beta Was this translation helpful? Give feedback.
-
|
I believe that workflow should continue to work with Docker using the host env to run the build, but do let me know if it stops working for some reason! |
Beta Was this translation helpful? Give feedback.
-
|
@TheKnarf can you try installing the platform-specific If you can run the binary from that package on the raspberry pi, you should be good to go. Even just running |
Beta Was this translation helpful? Give feedback.
-
|
Any chance to revert this? We need both linux-arm and linux-ppc64le and you caught us off guard by not respecting semantic versioning with this change: zwave-js/node-zwave-js#5164 |
Beta Was this translation helpful? Give feedback.
-
|
Heya @darkbasic! We're sorry for messing up your workflow. The two platforms you report needing are likely not a super-heavy lift. We've migrated to CGO as an enabler for an incremental Rust migration which means that we are no longer able to leverage the built-in Go cross-compilation strategy we were using previously. We're willing to support both of those platforms, but it's low priority for us to figure out the magic incantation for our build container that would enable targeting those architectures: https://github.com/vercel/turborepo/blob/main/buildcontainer/Dockerfile Would you be willing to help us figure out the magic build toolchain to support both of those architectures? |
Beta Was this translation helpful? Give feedback.
-
|
What's the problem with your current toolchain? I see there is already an armv7 toolchain here so it must be broken somehow, on the contrary I see no ppc64le toolchain. Maybe @madscientist159 can point us to one readily available. |
Beta Was this translation helpful? Give feedback.
-
I think that toolchain is only being brought in for Windows support on ARM. We don't need Windows support for ppc64el. ppc64el is very well supported on Debian, I suspect all you need to do is copy all the |
Beta Was this translation helpful? Give feedback.
-
We are intending on enabling
CGOacross the board forturboso that we can start interfacing with native libraries. This has the consequence of needing to put more effort into cross-compiling our Go code.To facilitate cross compilation, we would like to clearly specify which platforms
turbosupports and intends to support.The current proposal is to support each of:
on
Anyone using any of the above combinations will be unaffected by this change.
If there are
turbousers not using a platform listed above, we'd like to hear from you.turbois currently built for a variety of more esoteric platforms as well, but we have not identified usage for them via our remote cache stats. However, it is possible that there are users not using remote caching and building on a platform that is not covered by the above, and we'd like to make sure they have a path forward if at all possible.Packages we would no longer build:
Beta Was this translation helpful? Give feedback.
All reactions