FreeCAD for MacOS now more than 100 commits behind
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
FreeCAD for MacOS now more than 100 commits behind
I had tried to compile FreeCAD on the Mac pretty long time ago and gave up when I faced the first problems. So this is probably not the right time to start it again, since the expert have problems themselves.
But is there anything else I can do? Doing some research on error codes? Offer a cold beer on success?
But is there anything else I can do? Doing some research on error codes? Offer a cold beer on success?
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: FreeCAD for MacOS now more than 100 commits behind
This isn't meant to be snarky or whiny, but rather to the point:
In recent history, there have been <5 of us who have maintained the Mac builds, and I think all are professional computer people for their "real jobs". In other words, the combination of free time and willpower to work on computer stuff is somewhat precious. Homebrew had made some pretty big changes, which created a bunch of work for homebrew-freecad (I believe for good reasons), and it seems like there's been a general increase in "noise" within FreeCAD too (and, lots of good progress). Additionally, I think most folks find that packaging stuff just isn't much fun.
For me personally - most of my CAD-related projects lately have been more electronic than mechanical, so I've been using KiCad more than FreeCAD. I've also switched back to Linux, so have even less motivation to work on MacOS packaging.
The single biggest technical issue that I'm aware of is the slowness in PySide2 being packaged by the wider community - it may be the case that homebrew now has a PySide2, which would be great, because then we don't have to keep maintaining packages for it.
So, what to do? It would be great if someone could step in and help with triaging bugs/request/etc. to cut down on the administrative overhead - make it easy for people to help with the techincal stuff. A couple recent bugs in the homebrew-freecad tracker should frankly just be closed for being low quality reports (81, 90) or cross-posting / irrelevant (92). Or, jump right in and try to figure it out! I think the thing to do in the short term is to build FreeCAD on your own machine, starting with a version of code that was built successfully by Travis. In doing that, you may find that there has been some change in something that FreeCAD is dependant on. Alternatively, update the FreeCAD source until you run in to similar build problems.
In recent history, there have been <5 of us who have maintained the Mac builds, and I think all are professional computer people for their "real jobs". In other words, the combination of free time and willpower to work on computer stuff is somewhat precious. Homebrew had made some pretty big changes, which created a bunch of work for homebrew-freecad (I believe for good reasons), and it seems like there's been a general increase in "noise" within FreeCAD too (and, lots of good progress). Additionally, I think most folks find that packaging stuff just isn't much fun.
For me personally - most of my CAD-related projects lately have been more electronic than mechanical, so I've been using KiCad more than FreeCAD. I've also switched back to Linux, so have even less motivation to work on MacOS packaging.
The single biggest technical issue that I'm aware of is the slowness in PySide2 being packaged by the wider community - it may be the case that homebrew now has a PySide2, which would be great, because then we don't have to keep maintaining packages for it.
So, what to do? It would be great if someone could step in and help with triaging bugs/request/etc. to cut down on the administrative overhead - make it easy for people to help with the techincal stuff. A couple recent bugs in the homebrew-freecad tracker should frankly just be closed for being low quality reports (81, 90) or cross-posting / irrelevant (92). Or, jump right in and try to figure it out! I think the thing to do in the short term is to build FreeCAD on your own machine, starting with a version of code that was built successfully by Travis. In doing that, you may find that there has been some change in something that FreeCAD is dependant on. Alternatively, update the FreeCAD source until you run in to similar build problems.
Re: FreeCAD for MacOS now more than 100 commits behind
I don't know if the way in which @realthunder is doing his deployment could help also for OSX.
I know he helped also in automating the AppImage CV for Linux.
I know he helped also in automating the AppImage CV for Linux.
realthunder wrote: ping
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: FreeCAD for MacOS now more than 100 commits behind
My script can automate mac build, too, but you'll first need to setup homebrew environment. See the instruction in the readme. I guess the problem is usually the homebrew setup part. I remember having some when I first tired.
Re: FreeCAD for MacOS now more than 100 commits behind
There is also still some problem with the Travis MacOS build (it currently fails). I tried to see what's wrong but it's pretty unclear. The best I could find out is that there is a Qt version mismatch (some 5.0 vs 5.1 libs somewhere). But I cant figure out if it's a problem on travis or on our side...
Re: FreeCAD for MacOS now more than 100 commits behind
When looking at the macOS build then the build, the installation and the unit tests all work correctly. But at the very end it fails due to a missing command.
Other projects suffered from this problem too but somehow have managed to fix it.Done. Your build exited with 1.
/Users/travis/.travis/job_stages: line 187: shell_session_update: command not found
Re: FreeCAD for MacOS now more than 100 commits behind
But there is also an error message complaining about incompatible QT versions:
I think this is caused by a wrong line in .travis.yml
This works only, if there is one QT version installed. On my system I have two, which leads to two lines for the QT5_CMAKE_PREFIX. Perhaps following would be better:
which finds at least the newest installed QT version. I don't know if the application bundler finds the same version later.
Code: Select all
Log: Cannot mix incompatible Qt library (version 0x50b00) with this library (version 0x50b01)
Code: Select all
QT5_CMAKE_PREFIX=$(ls -d $(brew --cellar)/qt/*/lib/cmake)
Code: Select all
QT5_CMAKE_PREFIX=$(ls -d $(brew --cellar)/qt/*/lib/cmake | tail -n 1)
Re: FreeCAD for MacOS now more than 100 commits behind
Going around homebrew's back to get the available Qt versions probably isn't the way to solve that problem. Homebrew should be linking only one Qt version for any particular Qt package, it wouldn't surprise me if the issue is essentially that there's a newer Qt shipping with Homebrew now, and we're packaging Qt5.6-specific stuff. Sorry I can't remember the specifics offhand, but there's a "brew" command to give the path to the selected Qt install.tom wrote: ↑Thu Jul 26, 2018 5:55 pmPerhaps following would be better:which finds at least the newest installed QT version. I don't know if the application bundler finds the same version later.Code: Select all
QT5_CMAKE_PREFIX=$(ls -d $(brew --cellar)/qt/*/lib/cmake | tail -n 1)
Also, Qt have an official PySide2 out now (though I haven't figured out how to get their official Shiboken2 binaries - has anyone here?). We should switch to using that for MacOS builds, which I suspect would make it easier follow the Homebrew Qt version as well.
Re: FreeCAD for MacOS now more than 100 commits behind
Does this mean that it loads two Qt versions at runtime or does it only mean that a library links against Qt 5.11.1 when 5.11.0 is expected (or the other way round)?Log: Cannot mix incompatible Qt library (version 0x50b00) with this library (version 0x50b01)
At least Qt 5.11.0 and Qt 5.11.1 are binary compatible and it should not cause a problem if a library at runtime references another version than it was built for.
Re: FreeCAD for MacOS now more than 100 commits behind
I guess that latter one. IMHO following happens:
- ls -d $(brew --cellar)/qt/*/lib/cmake finds two QT versions, but 5.11.0 is the first one in the list. So, for cmake 5.11.0 becomes effective.
- 5.11.0 is somewhere in a QT header file, so that the FreeCAD application gets 5.11.0 into its binary.
- The OS X app bundler tries to resolve all libraries need to run the application, but it finds the latest QT libraries, i.e. and puts them into the bundle.
- At execution time the version of the bundled shred library is compared against the QT version compiled into the application binary.