tuning x11-64 platform for aarch64 and pyhton3.9

[jfrey-xx]

Hello,

First of all, thank you for this project, this is amazing that we can run Python scripts within Godot. I only scratched the surface but it already open many doors, not only for the language per se, but because there tons of libraries that can be now be employed alongside the game engine.

Some weeks ago I tried to run godot-python on Raspberry Pi (Raspberry Pi OS / Debian Buster). It failed because this is not something that is planned in current code, and because aarch64 was only recently added to the underlying python-build-standalone (and it is still a work in progress).

After some time hacking my way through the code, I managed nonetheless to make it work. I added some instructions in the README, the broader picture is detailed in a tutorial here https://labs.ullo.fr/tutorials/python-and-godot-engine-on-a-raspberry-pi-displaying-physiological-signals-with-lsl/ Note that only python 3.9, not 3.8, is supported by python-build-standalone for aarch64. It did not seem to be an issue but I did not test thoroughly every feature of godot-python.

This pull request is not to be merged as is, because I went fast and simply replaced the existing x11-64 platform. Now, others might be interested in running and Godot and Python on a Raspberry (or on other aarch64 linux systems). What would be the best way to integrate those changes? Create a dedicated platform, e.g. x11-64-arm (maybe with an "-experimental" flag)?

[touilleMan]

Wow this is really cool !

This pull request is not to be merged as is,

I've converted the PR as draft to reflect this

but because there tons of libraries that can be now be employed alongside the game engine.

Yes, that's the main selling point for using Python instead of GDscript ^^ I don't much about Python ecosystem on Raspberry, is it easy to pip install binary dependencies ?

the broader picture is detailed in a tutorial here

This is a really nice tutorial, do you mind if I add it to the README ? (it could help people trying to use pip on top of using raspberry)

What would be the best way to integrate those changes? Create a dedicated platform, e.g. x11-64-arm (maybe with an "-experimental" flag)?

Adding a new platform seems like the way to go.

However I'm not sure how we could test the platform on the CI. Maybe we could use an emulator, but given Raspberry support for Godot is not official, we may endup with fragile code (especially when Godot 4 will be released) and I won't have any experience to support this.

I think the simplest thing to do would be to add the platform, but with no guarantees whatsoever (so no CI is run against it, people using Raspberry could submit PR to fix issues but no effort would be done to check for changes compatibility)

Another solution would be for you (or anybody interested in supporting Raspberry) to fork Godot-Python and add the new platform from there (typically using git subtree to simplify synchronization with the upstream Godot-Python).

Again, Godot 4 brings a complete breakage of the GDNative API so I can't guarantee how much the Godot-Python codebase will change to support this (in theory the platform stuff should not change that much given it's mostly the interface with Godot that is modified, but who knows ! ^^).

[jfrey-xx]

It is as easy to install libraries on Raspberry as everywhere else, it is just that sometimes in pip the versions on ARM lag behind other platforms, and it happened to me a couple times that I had to compile some bits by hand because maintainers did not anticipate that their package could be installed on such CPU.

Concerning the tutorial it would be my honor to appear in the README ;)

I did not follow Godot development -- truth to be told I am very new at Godot -- I had no idea GDNative could break, finger crossed then!

As you say the whole port is at an early stage, it makes sense to leave it aside from the "official" releases, especially if it is difficult to do cross-compilation (I am not even sure we could automate the retrieval of linux aarch64 builds from python-build-standalone at this stage).

I would not have enough spare time to maintain a fork, but I can try to work on the pull request to create this dedicate platform :)