FreeCAD for MacOS now more than 100 commits behind

[chrisb]

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?

[ian.rees]

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.

[easyw-fc]

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.

ping

[realthunder]

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.

[yorik]

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...

[wmayer]

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.

Done. Your build exited with 1.

/Users/travis/.travis/job_stages: line 187: shell_session_update: command not found

Other projects suffered from this problem too but somehow have managed to fix it.

[tom]

But there is also an error message complaining about incompatible QT versions:

Code: Select all

Log: Cannot mix incompatible Qt library (version 0x50b00) with this library (version 0x50b01)

I think this is caused by a wrong line in .travis.yml

Code: Select all

QT5_CMAKE_PREFIX=$(ls -d $(brew --cellar)/qt/*/lib/cmake)

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:

Code: Select all

QT5_CMAKE_PREFIX=$(ls -d $(brew --cellar)/qt/*/lib/cmake | tail -n 1)

which finds at least the newest installed QT version. I don't know if the application bundler finds the same version later.

[ian.rees]

Perhaps following would be better:

Code: Select all

QT5_CMAKE_PREFIX=$(ls -d $(brew --cellar)/qt/*/lib/cmake | tail -n 1)

which finds at least the newest installed QT version. I don't know if the application bundler finds the same version later.

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.

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.

[wmayer]

Log: Cannot mix incompatible Qt library (version 0x50b00) with this library (version 0x50b01)

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)?

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.

[tom]

Log: Cannot mix incompatible Qt library (version 0x50b00) with this library (version 0x50b01)

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)?

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.

All that is only a guess, but it suits the observations in the travis log file.