FreeCAD for MacOS now more than 100 commits behind

Having trouble installing or compiling FreeCAD? Get help here.
chrisb
Posts: 18092
Joined: Tue Mar 17, 2015 9:14 am

FreeCAD for MacOS now more than 100 commits behind

Postby chrisb » Thu Jul 19, 2018 11:09 am

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
Posts: 696
Joined: Sun Jun 15, 2014 3:28 am
Contact:

Re: FreeCAD for MacOS now more than 100 commits behind

Postby ian.rees » Thu Jul 26, 2018 2:57 am

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.
User avatar
easyw-fc
Posts: 2627
Joined: Thu Jul 09, 2015 9:34 am

Re: FreeCAD for MacOS now more than 100 commits behind

Postby easyw-fc » Thu Jul 26, 2018 5:24 am

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.
realthunder wrote: ping
realthunder
Posts: 1166
Joined: Tue Jan 03, 2017 10:55 am

Re: FreeCAD for MacOS now more than 100 commits behind

Postby realthunder » Thu Jul 26, 2018 7:11 am

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.
Try Assembly3 (latest version 0.10.2) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
yorik
Site Admin
Posts: 11514
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: FreeCAD for MacOS now more than 100 commits behind

Postby yorik » Thu Jul 26, 2018 1:26 pm

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
Site Admin
Posts: 14782
Joined: Thu Feb 19, 2009 10:32 am

Re: FreeCAD for MacOS now more than 100 commits behind

Postby wmayer » Thu Jul 26, 2018 4:57 pm

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
Posts: 65
Joined: Sun Mar 29, 2015 9:20 pm

Re: FreeCAD for MacOS now more than 100 commits behind

Postby tom » Thu Jul 26, 2018 5:55 pm

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
Posts: 696
Joined: Sun Jun 15, 2014 3:28 am
Contact:

Re: FreeCAD for MacOS now more than 100 commits behind

Postby ian.rees » Thu Jul 26, 2018 8:29 pm

tom wrote:
Thu Jul 26, 2018 5:55 pm
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
Site Admin
Posts: 14782
Joined: Thu Feb 19, 2009 10:32 am

Re: FreeCAD for MacOS now more than 100 commits behind

Postby wmayer » Fri Jul 27, 2018 7:53 am

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
Posts: 65
Joined: Sun Mar 29, 2015 9:20 pm

Re: FreeCAD for MacOS now more than 100 commits behind

Postby tom » Fri Jul 27, 2018 2:39 pm

wmayer wrote:
Fri Jul 27, 2018 7:53 am
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.