Closed nerohmot closed 3 years ago
We've been ok having different versions for aarch than for x64. But in reality, we will need many CDTs for qt, and those are tedious, and not so fun.
If you can help knock some of them out, that would be great!
But in reality, we will need many CDTs for qt, and those are tedious, and not so fun.
Indeed, so pulling resources might be the answer :yum:
We've been ok having different versions for aarch than for x64.
I am interested in a pyqt for aarch64 ... where can I find that ?
On an Ubuntu 20.04 running on ARM I don't find anything on conda-forge ... there might be other channels though :crossed_fingers:
Anyway a newer and consistent Qt for Windows/Linux/macOS on x86_64
should be the first concern.
In October Big Sur will be there ... curious to see how long it will take Apple to also release aarch64
devices ... then, -as-they-say- "shit hits the fan", also for anaconda I recon :laughing:
apologies ... the title of the issue should be of course "pooling resources" ... kind of the opposite :dizzy_face: ... sorry, it was late :wink:
I am interested in a pyqt for aarch64 ... where can I find that ?
Tom, I was able to compile PyQt 5.15 natively on a Jetson AGX Xavier. I also compiled PySide2. I have no problem detailing what I did if that helps creating an official package for the architecture; it was actually quite straightforward, just had to be careful with all the prerequisites.
I have Qt 5.15.5, PyQt 5.15 and Spyder 4 builds (for Windows 64-bit) available on https://anaconda.org/rdonnelly. Other builds to follow.
As the primary contributor to Qt in both Anaconda Defaults and conda-forge, can you please remember to tag @mingwandroid when discussing Qt? Thanks!
@hmaarrfk this has nothing to do with CDTs which I find neither tedious nor non-fun.
They can be fun! In moderation
I understand that @andreacogliati managed to compile (https://github.com/conda-forge/miniforge/issues/46) Qt 5.15, but has trouble in packing ... @rgommers, couldn't @ilanschnell help out here?
BUT ... we need to be careful, 5.15 will be around for several years and many projects will depend on it, so the builds for Windows/Linux/macOS should be the same! Not like the 5.12 where in Linux (an old version) of gstreamer is blended in whereas in the Windows equivalent it isn't ... (maybe that's the reason why anaconda is still using the aged 5.9.2 ?!?)
Don't get me wrong, I :heart: gstreamer! As a matter of fact, @ccordoba12, the screen-cast plugin for spyder (>=5) will use it, but we will get in trouble if the Windows/Linux/macOS versions don't match up!
IMHO, it is better to leave gstreamer out of the Qt 5.15 equation, and leave it to the gstreamer-feedstock to add the python bindings there. Even better, @goanpeca they could link against QtPy and not get into the nitty-gritty of licensing :rofl: