Sorry I’ve been AWOL, I just passed your second patch on so one of the others can look at it. In the meantime, we’ve just disabled scripting on macOS builds so macOS users can have something.
still get
Scanning dependencies of target pcbnew_python_module
make[2]: *** No rule to make target kicad/kicad.app/Contents/PlugIns/_pcbnew.kiface', needed by pcbnew/CMakeFiles/pcbnew_python_module’. Stop.
make[1]: *** [pcbnew/CMakeFiles/pcbnew_python_module.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs…
may want to try nuking your build folder and trying that fresh
There is now a nightly build up for macOS, with Python scripting disabled. I’ll update here when Python is enabled again.
1 Like
Thanks very much Rivimey, that has made the build progress much further, I actually get a working build now of Kicad.app - with Python! - and all of the targets seem to work when launching via the Kicad.app! The install/packaging process actually fails however, with the following error. I’m fairly sure it’s unrelated to your patch though so may require a separate bug report, which I’m happy to do. (I’m using the Mac install script kicad-app.sh)
One part disables the findpackage for OpenMP, which is not found (not present??) on apple clang.
Apparently OpenMP is now built-in to Apple’s Clang, but it seems some envs aren’t set so the configure script doesn’t know how to use it. I attempted to install the now depreciated clang-omp from the Brew “boneyard”, but the config script still couldn’t find the libraries 
[apologies for the long error post!]
-- fixup_bundle: preparing...
--
warning: cannot resolve item '@rpath/libtbb.dylib'
possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?
-- warning: gp_resolved_file_type non-absolute file '@rpath/libtbb.dylib' returning type 'other' -- possibly incorrect
--
warning: cannot resolve item '@rpath/libtbb.dylib'
possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?
--
warning: cannot resolve item '@rpath/libtbbmalloc.dylib'
possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?
-- warning: gp_resolved_file_type non-absolute file '@rpath/libtbbmalloc.dylib' returning type 'other' -- possibly incorrect
--
warning: cannot resolve item '@rpath/libtbbmalloc.dylib'
possible problems:
need more directories?
need to use InstallRequiredSystemLibraries?
run in install tree instead of build tree?
warning: target '@rpath/libtbb.dylib' is not absolute...
warning: target '@rpath/libtbb.dylib' does not exist...
CMake Error at /usr/local/Cellar/cmake/3.7.2/share/cmake/Modules/GetPrerequisites.cmake:818 (message):
/usr/bin/otool failed: 1
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/objdump:
'@rpath/libtbb.dylib': No such file or directory.
fatal error:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool:
internal objdump command failed
Call Stack (most recent call first):
/usr/local/Cellar/cmake/3.7.2/share/cmake/Modules/GetPrerequisites.cmake:943 (get_prerequisites)
/usr/local/Cellar/cmake/3.7.2/share/cmake/Modules/BundleUtilities.cmake:575 (get_prerequisites)
/usr/local/Cellar/cmake/3.7.2/share/cmake/Modules/BundleUtilities.cmake:848 (get_bundle_keys)
kicad/cmake_install.cmake:87 (fixup_bundle)
cmake_install.cmake:69 (include)
make[1]: *** [install] Error 1Hi, I was using kicad-build.sh as well. I do have a modified version of it but I introduced a bug too :). I was trying to make the script more robust. The original script will build kicad in the ‘bin’ fiolder. I haven’t tried further: copying that folder into a suitable Applications place is all that was needed for me.
I’m afraid I have little knowledge of the specific warnings you list, but libtbb (from the tbb package) seems to be required by swig. Perhaps updating your brew installation would be useful, i.e. brew update then brew upgrade?
This is the NON-WORKING version of the script I mentioned. It gets the wxpython build messed up, but I think there are some good things going on too 
kicad-app.sh (11.6 KB)
@c4757p,
One thing for the build servers: the kicad-build.sh file sets the OS version to 10.12; those of us (like me) who are still on El Capitan will find such builds won’t run. I can build it very happily with it set to 10.11.
may i ask what problems you had with the original kicad-app.sh?
And it might help if you distribute your .sh with the patches for wxwidgets as they are rather required for all the cool crap in kicad (and required to actually have wxwidgets build iirc)
I started fiddling with kicad-app.sh because the internal command help didn’t match the actual commands, and then I started breaking down some of the steps so that I could better control the build stages, and also changed the cmake step, so changes in CMakeList.txt were accounted for in a rebuild. For various reasons including robustness I felt it was better to set the cuttent directory explicitly, rather than use relative "cd"s.
I’m not really understanding the comments re patches; although I added one patch for my own build, it only fixes a compiler warning. I would be happy for it to be used generally if that is what you’re asking. As part of my build I did of course compile wxwidgets and am using that in my local build of kicad.
make will redo cmake if CMakeLists.txt has changed
My experience differs… perhaps because I was changing pcbnew/CMakeLists.txt?? Anyway, while debugging the mac build I found it was necessary.
I’ve found this to be pretty inconsistent. If I edit CMakeLists.txt in a very simple way (e.g. just adding a source file to the list) it works fine, but if I do bigger things like adding build/config options it needs to be redone…
It seems the nightlies have broken again, since April 8th. I’ve tried compiling Kicad with the script from here (official script) but it fails while trying to build wxwidgets. I fiddled around a bit and managed to get wxWidgets built, but the kicad_build command seemed to give up after compiling wxWidgets with no errors; no Kicad binary was produced. No idea why, maybe the build structure has changed?
@rivimey’s script seems to have broken too, it stops when compiling wxWidgets, with quicktime.h (depreciated since 10.7) not found; her script passes --disable-mediactrl which should fix the error according to wxWidgets mailing list, but it doesn’t for some reason. I think the newer versions of wxWidgets have resolved the quicktime.h problem, but since Kicad uses an ancient patched version, updating wxWidgets is almost impossible. Would you happen to have an updated version @rivimey?
Thanks for any prospective pointers…!
[edit] I have discovered this which should fix the nightlies, but seemingly hasn’t been committed?
The macos nightlies are up again. Please continue testing! 
2 Likes
I have been trying to compile my own binary for a while now; I have had a lot of problems compiling wxpython with various errors, and eventually decided to try out phoenix, the current beanch of wxpython. It does build, but there are lots of dependencies between the kicad build script and the layout of (old) wxpython and I haven’t got to the bottom of them yet. I have hope, though.
In the meantime, it would be good for someone knowledgable to post the method the build server is using, as it seems to me there must be some difference – perhaps in the environment?
A last note, I did see that it is possible to ‘hire’ macosx machines in an Amazon/EC2 style. Has anyone investigated this route any further?
Ruth
See the recent postings on the mailing list. Chris Pavlina @c4757p is reporting there.
https://lists.launchpad.net/kicad-developers/
It just uses homebrew, it is not magic as such.