Would love to see M1 Mac builds (AArch64 binary) in 5.99 nightly. Now more ARM Macs are available out there (>80% listed in apple.com are ARM based Macs). Also, there are significant performance improvements when you run ARM native binary in M1 Macs with amazing power efficiency.
We would love to see Apple stop being hostile to developers and actually provide technical documentation worth more than toilet paper 
Or remember to update it after posting it 6 years ago, etc, etc.
It’ll happen eventually, Apple packaging is a one man show and he’s constantly overwhelmed with things breaking weekly. It is the only platform that’s an absolute nightmare to develop on.
3 Likes
I agree that Apple forces developers to follow their way without any freedom. I have quite a long experience with their iOS SDK. But documentation side I have never felt they are outdated (maybe just on the iOS side)
Also, I totally understand the resource constrain and really appreciate the effort from the team 
Regarding generating an ARM binary or Universal binary for existing macOS Apps, it is pretty straight forward and just a matter of re-compiling the code (most of the cases). Unless there is any hardware specific feature or assembly code in the codebase.
I can see there is already a merge request in macOS packaging repo which is compilable for M1 Mac. So I guess KiCad source code is pretty straight forward and there is no code change required to compile and re-generate ARM binary for Mac.
There should be no problem with people compiling themselves for M1. The extra effort being asked for is publishing official M1 builds, which requires our packager to set up another build pipeline in parallel, do QA on the M1 build before releases, etc.
Unfortunately, I was unable to compile it for myself.
I followed the official mac os build guide, but I ended up with this error while running cmake with parameters generated by build.py
wxPython/Phoenix does not appear to be installed on the system
After I set these flags to ‘OFF’:
-DKICAD_SCRIPTING_WXPYTHON=OFF \
-DKICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF \
I was able to generate makefile but it failed with this error:
pybind11::detail::type_caster<bool, void>& pybind11::detail::load_type<bool, void>(pybind11::detail::type_caster<bool, void>&, pybind11::handle const&) in libscripting.a(python_scripting.cpp.o)
ld: symbol(s) not found for architecture arm64
What can I try next?
EDIT:
I actually had to modify arguments generated by build.py script to point to brew packages. Now the build finishes
-DDEFAULT_INSTALL_PATH=/Library/Application Support/kicad \
-DOCC_INCLUDE_DIR=/opt/homebrew/Cellar/opencascade/7.5.3/include/opencascade \
-DOCC_LIBRARY_DIR=/opt/homebrew/Cellar/opencascade/7.5.3/lib \
-DCMAKE_INSTALL_PREFIX={Path to kicad-mac-builder}/build/kicad-dest \
-DCMAKE_C_COMPILER=/usr/bin/clang \
-DCMAKE_CXX_COMPILER=/usr/bin/clang++ \
-DCMAKE_OSX_DEPLOYMENT_TARGET=12.0 \
-DwxWidgets_CONFIG_EXECUTABLE={Path to kicad-mac-builder}/build/wxwidgets-dest/bin/wx-config \
-DKICAD_BUILD_I18N=ON \
-DKICAD_SCRIPTING_PYTHON3=ON \
-DKICAD_SCRIPTING=ON \
-DKICAD_SCRIPTING_MODULES=ON \
-DKICAD_SCRIPTING_WXPYTHON=OFF \
-DKICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF \
-DKICAD_SCRIPTING_ACTION_MENU=ON \
-DPYTHON_EXECUTABLE=/opt/homebrew/bin/python3 \
-DPYTHON_INCLUDE_DIR=/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9 \
-DPYTHON_LIBRARY=/Library/Frameworks/Python.framework/Versions/3.9/lib/libpython3.9.dylib \
-DPYTHON_SITE_PACKAGE_PATH=/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages \
-DPYTHON_FRAMEWORK=/Library/Frameworks/Python.framework \
-DKICAD_USE_OCE=OFF \
-DKICAD_USE_OCC=ON \
-DKICAD_SPICE=ON \
-DNGSPICE_INCLUDE_DIR=/opt/homebrew/Cellar/libngspice/35/include \
-DNGSPICE_LIBRARY=/opt/homebrew/Cellar/libngspice/35/lib/libngspice.dylib \
-DMACOS_EXTRA_BUNDLE_FIX_DIRS=/opt/homebrew/opt/fftw/lib \
-DCMAKE_BUILD_TYPE=RelWithDebInfo -G Ninja
as you can see I built it with python3.9 universal binary avaliable at python’s webpage
but ‘ninja install’ fails with this message
CMake Error at /opt/homebrew/Cellar/cmake/3.21.4/share/cmake/Modules/BundleUtilities.cmake:1128 (message):
error: verify_app failed
Call Stack (most recent call first):
/opt/homebrew/Cellar/cmake/3.21.4/share/cmake/Modules/BundleUtilities.cmake:995 (verify_app)
gerbview/cmake_install.cmake:84 (fixup_bundle)
cmake_install.cmake:67 (include)I believe @adamwolf will be testing M1 and solving problems after the 6.0 release sometime. None of the other developers have a new Mac so I’m not sure we can offer specific useful advice yet.
1 Like
I’m really looking forward to it. I’d love to have native M1 builds!
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.