cycling74 / max-package-template Goto Github PK

I'm just getting started with building Max externals using max-sdk on an Apple M1 Pro machine. I found that when I followed the instructions in the README for this project, the resulting build created an external compiled for x86_64 only, instead of arm64 or a universal binary.

See build log at https://gist.github.com/TimMoore/00c4009841938a286626b0c13e2182b3

I tried to regenerate the Xcode project file with the command cmake --trace-expand -G Xcode .. to see more details, and saw this warning in the output:

/opt/homebrew/Cellar/cmake/3.24.2/share/cmake/Modules/Platform/Darwin-Initialize.cmake(20):  set(CMAKE_OSX_ARCHITECTURES  CACHE STRING Build architectures for OSX )
CMake Warning (dev) at /opt/homebrew/Cellar/cmake/3.24.2/share/cmake/Modules/Platform/Darwin-Initialize.cmake:20 (set):
  Policy CMP0126 is not set: set(CACHE) does not remove a normal variable of
  the same name.  Run "cmake --help-policy CMP0126" for policy details.  Use
  the cmake_policy command to set the policy and suppress this warning.

  For compatibility with older versions of CMake, normal variable
  "CMAKE_OSX_ARCHITECTURES" will be removed from the current scope.
Call Stack (most recent call first):
  /opt/homebrew/Cellar/cmake/3.24.2/share/cmake/Modules/CMakeSystemSpecificInitialize.cmake:21 (include)
  CMakeLists.txt:6 (project)
This warning is for project developers.  Use -Wno-dev to suppress it.

The full output is very long, but is available at https://gist.github.com/TimMoore/42326a52ccfe8d1103c4172e9b59a458

I believe the issue is in this line of the CMake configuration:

According to the CMake documentation for the CMAKE_OSX_ARCHITECTURES variable:

This variable should be set as a CACHE entry (or else CMake may remove it while initializing a cache entry of the same name) unless policy CMP0126 is set to NEW.

Changing that line of CMakeLists.txt to the following fixes the problem and builds a universal binary:

set(CMAKE_OSX_ARCHITECTURES x86_64;arm64 CACHE STRING "Enable Apple Silicon Builds")

Hi,

Thanks for this template repo!

I was just reading through the main.yml workflow and I noted that you were using cp -r to copy external bundles for macos platforms:

if [ -d externals ]; then cp -r externals $PACKAGE_NAME; fi

I'm not sure this is best practice. The use of cp -r is discouraged per se, but particularly problematic for bundles which are likely to contain symlinks (if they are non-trivial).

See this text at the bottom of the macos cp man file:

COMPATIBILITY
     Historic versions of the cp utility had a -r option.  This implementation
     supports that option; however, its use is strongly discouraged, as it
     does not correctly copy special files, symbolic links, or fifo's.

As a suggestion, it's probably better to use cp -a or ditto to preserve symlinks and / or code signatures.