-
-
Notifications
You must be signed in to change notification settings - Fork 512
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MAVSDK verson on macOS aarch64 #1989
Comments
Yes, that's currently broken. The main pain point is that GitHub actions doesn't have macOS M1/2 runners, and so it's not easy to release the binary. Besides that, something is wrong with how the architecture gets downloaded or is compatible and so the recent releases don't work. Pull requests to fix it would be most welcome. |
@julianoes quick question... so I was able to install the aarch64 version of mavsdk_server v1.4.12 via home-brew... but this only includes the C++ interface library, not the python version. Can I build/install the mavsdk_python package from the source? I am not sure how this is done as I have never built a python package that could then be installed via pip. Do you know where I can find a guide on how to build the pip package? Also, looking at the two posts you provided above... here...
This only checks if the platform is macOS.. and not the architecture. This probably defaults to x86. The code for Linux checks the architecture. I can probably fix that and submit a pull request if I can figure out how to build/install the python package. Any pointers would be most helpful. |
@julianoes scratch my last. I was able to clone the repo and followed the instructions at the bottom of the README.md. When I first saw them, I did not realize that they build the python sdk. I was expecting something talking about building a wheel and what not. I have never built a python package from source. Anyway, the instructions worked flawlessly and I was able to build MAVSDK version 1.4.12 for aarch64 on M1. Seems to work just fine. I can see mavsdk installed in pip as well as the mavsdk_server in the local bin folder. |
That's great! Are you detecting the M1 around here? Then the problem we have is that we don't have a CI for the M1 that could build |
So for my current immediate need, I used The code block that you highlighted is one of the problems. It appears to detect that the platform is MacOS (i.e., Darwin) but does not check the architecture. I am also still determining how a python library is built (i.e., setup.py) for distribution, so I need to understand how that works. I use them a lot.. just never had to build one :) |
Oh, so homebrew actually builds MAVSDK for the M1 and ships the binary? Is there a way to download that binary directly (say with Maybe @ZhongRuoyu or @chenrui333 would have an insight about that? It would solve our problem. Right now we fetch |
They do have a formula for x86 MacOS as well as Apple Silicon for Ventura, Monterey, and Big Sur, but looking at the formula, it appears to actually build the executable on the user's workstation (using gcc or clang) rather than installing a pre-compiled binary. Does the python package distribution system allow one to do something similar (i.e., build the binary locally rather than download it)? The recipe code is here Until GitHub has the CI runners for Apple aarch64, it will still be an issue of where the actual build happens. I am surprised they do not support it yet. I did see a blog post that their CI system supports "self-hosted" M1 runners. Still, I don't see how that is different from the developer building on their workstation and copying the executable up to the release folder. Self-hosted, in this case, does not appear to be that helpful. |
Oh actually @julianoes wrote the original recipe, I had forgotten that 😆.
Probably, but at this point, maybe we could just have MAVSDK-Python rely on a system-wide Then around here, instead of running the embedded What do you think? |
Perfect! The homebrew install path differs for M1 ( I use the |
Oh that's a very good point... it may cause strange behaviors. I guess to warn users we could add a way to call But maybe let's start by having it take the |
Yes, we do. The pre-built binaries are called bottles, and they are hosted here on GitHub.
You may use But please note that bottles are not necessarily ready for use; they need to be poured (processed) by Homebrew before that. 1 Here's what you'll likely see when download the fetched bottle, extract it, and run the executable. So, from what I learned from the context of this issue, I'm afraid that this may not work.
Footnotes |
@ZhongRuoyu: thanks a lot for the insights! So I guess the best way is to tell the user to install it with homebrew when the M1 is detected (instead of automatically trying to fetch the executable). |
Done in #2277. |
I am working on a Mac M1 (aarch64) and was able to install mavsdk from homebrew, which installs
mavsdk_server
version 1.4.12. However, this does not install the Python3 bindings. When trying to installmavsdk-python
from PyPi viapip3 install mavsdk
, the only versions available are0.5.2, 0.7.0, 0.8.0, 0.8.1, 0.8.2, 0.9.0, 0.9.1, 0.10.0, 0.11.0, 0.12.0
. None of these versions include the mavsdk_server executable and all are really old. This does not seem to be the case if installing via pip on x86 Mac, as the latest versions are available.I am sure it is possible to compile the latest version (1.4.12) of the python bindings, but I am not sure how to do that or how to install it into my python virtual environment (miniconda) once it is built.
The text was updated successfully, but these errors were encountered: