FreeCAD and Raspberry Pi 4

[easyw-fc]

Unfortunately, Python 2 is going to become unsupported very soon

An option could be to build for Qt4 & Py3.

[vocx]

...
Hereby I can confirm a successful build on the Pi4. I used the source of 0.18.3. As far as I can see everything is working.
...

Why don't you test with 0.19? Better to look at the future.

[vocx]

Awesome!
Is there anyone working on a py3 port as well ?

It's already ported to Py3 and Qt5. The problem is that there are some errors with Coin3D. So this needs to be investigated further.

[Kunda1]

It's already ported to Py3 and Qt5. The problem is that there are some errors with Coin3D. So this needs to be investigated further.

Thanks

[MartijnD]

Hereby I can confirm a successful build on the Pi4. I used the source of 0.18.3. As far as I can see everything is working.

Why don't you test with 0.19? Better to look at the future.

My goal was to have a stable build working on my Raspberry Pi, because I want to work with it The day before yesterday the build status of the master branch (0.19) on github was marked as "failing" that's why I took the 18.3 to build. If you guys need to have more information on the failing Coin3D library I'am willing to help, but you'll have to guide me bit

[kkremitzki]

I finally got my Raspberry Pi 4. This thing runs so smoothly!

I compiled from master yesterday and the issue is still present there.

[vocx]

...the build status of the master branch (0.19) on github was marked as "failing" ...

That doesn't mean much. The Travis continuous integration system may report failures for different reasons, but still compile fine once in the system.

[wmayer]

Unfortunately, Python 2 is going to become unsupported very soon https://pythonclock.org, so trying to make it work with Python 3/Qt5 should be a priority. So, the problems are due to Coin3D and Qt5 libraries, I think. Maybe Quarter?

With Qt5 the OpenGL support has significantly changed internally and to me the question is how do Coin3d and Qt5 work together. From the previous crash reports we can clearly see that Coin3d struggles with the OpenGL context and I wonder if this is something we can control.

For Windows we already know that with Qt 5.12 (maybe already with Qt 5.11) we need to set some Qt attributes to make Qt5 cooperate with Coin3d. I can imagine that on other platforms we have similar problems. Unfortunately, the solution for Windows doesn't work on other platforms.

So, if there is a possibility to switch back to an older Qt5 version then I would like to see if the combination Py3/Qt5.9 or Py3/Qt5.10 works on a Raspberry Pi.

[-alex-]

Awesome! I'm a genius!

Almost, you'll be a genius if you fixe the Freecad Py3/Qt5 build

I am impressed by your success and disappointed not to be able to do so much.

Thanks for your kind words, don't be disapointed, by following this post if I am sure you can success to compile Freecad yourself
BTW, the 0.18.3 realese should be available soon in Raspbian repo accordingly to the action of K.Kremitzki.

Hereby I can confirm a successful build on the Pi4. I used the source of 0.18.3. As far as I can see everything is working.
Hope it helps someone.
...
Best regards and keep up the good work!

Hi Martijn, sure it helps. Compile 0.18.3 was the next step on my todo list. You already did it, thanks you for the information

I will get in touch with the Raspberry Pi people since they mentioned they can help get the package fixed in their repos. I can provide a diff of the debian directory which would be enough for them to switch the packaging to Py2/Qt4 which would at least get things working for now.
....
I finally got my Raspberry Pi 4. This thing runs so smoothly!

Thank you for your action
And enjoy your RPI4, it runs so smouthly indeed
For people who are interested in, 3D graphics are well accelerated (when no bug by using Py2/Qt4 build), and temperature is about 50/55°C with passive cooling (with large heatsink and good contact with proc).

...
Hereby I can confirm a successful build on the Pi4. I used the source of 0.18.3. As far as I can see everything is working.
...

Why don't you test with 0.19? Better to look at the future.

IMHO it make sens to compile 0.18.3 because it the laste stable release anounced as reliable whith Py2/Qt4, until it is available in repo at least.

Unfortunately, Python 2 is going to become unsupported very soon https://pythonclock.org, so trying to make it work with Python 3/Qt5 should be a priority. So, the problems are due to Coin3D and Qt5 libraries, I think. Maybe Quarter?

With Qt5 the OpenGL support has significantly changed internally and to me the question is how do Coin3d and Qt5 work together. From the previous crash reports we can clearly see that Coin3d struggles with the OpenGL context and I wonder if this is something we can control.

For Windows we already know that with Qt 5.12 (maybe already with Qt 5.11) we need to set some Qt attributes to make Qt5 cooperate with Coin3d. I can imagine that on other platforms we have similar problems. Unfortunately, the solution for Windows doesn't work on other platforms.

So, if there is a possibility to switch back to an older Qt5 version then I would like to see if the combination Py3/Qt5.9 or Py3/Qt5.10 works on a Raspberry Pi.

About compiling: I tried to disable a lot of workbenches with CmakeGui in order to decrease the time of compiling, but compiling failed at 75%.
Maybe I disabled to much workbenches, I don't know. Is there rules about that?
Anyway, next step: compile Py3/Qt5.9 or 10. Ok
But now no time, see you

[vocx]

IMHO it make sens to compile 0.18.3 because it the laste stable release anounced as reliable whith Py2/Qt4, until it is available in repo at least.

Yes, it's fine to compile against 0.18, however, 0.19 is in active development and it brings so many new features over 0.18, that it would be great to make it work as well. Right now a 0.18 version is great to have, but in a few months, when 0.19 is ready to become the next stable version, it would be good to offer it as well in Raspbian, even in a Py2/Qt4 combination, but preferably with Py3/Qt5.

About compiling: I tried to disable a lot of workbenches with CmakeGui in order to decrease the time of compiling, but compiling failed at 75%.
Maybe I disabled to much workbenches, I don't know. Is there rules about that?...

Which ones? The only really required workbench is probably Part. All others basically depend on this. If you open the workbench selector, you see a list of all public workbenches, I think all of these can be deactivated, say, Arch, TechDraw, Path, FEM, etc.

If I were to test things, I would probably only enable Part and Start.

There are other modules like Tux, Import, and AddonManager. These aren't proper workbenches, but rather they provide internal support for certain options of FreeCAD, such as the mouse navigation, and the import system. I would leave these enabled as well. That is, I would only disable those that are accessible through the workbench selector.