Imported to branch https://github.com/openscad/openscad/tree/python3-macos to trigger the macos Circle-CI build.

Branch updated, trying to not pin a specific python3 minor version.

Still not happy

ls: /opt/homebrew/bin/python3.*: No such file or directory
Detected OS: MACOSX
OPENSCADDIR=/Users/distiller/project
DEPLOYDIR=/Users/distiller/project/build
OPENSCAD_LIBRARIES=/Users/distiller/project/../libraries/install
Checking pre-requisites...
error: patch failed: src/third_party/thrust/thrust/detail/type_traits.h:144
error: src/third_party/thrust/thrust/detail/type_traits.h: patch does not apply
error: patch failed: src/third_party/thrust/thrust/detail/type_traits/has_trivial_assign.h:39
error: src/third_party/thrust/thrust/detail/type_traits/has_trivial_assign.h: patch does not apply

==> [email protected]
Python has been installed as
/usr/local/bin/python3.9

-- Found PythonInterp: /usr/local/bin/python3.11 (found version "3.11.2")
-- Found PythonInterp: /usr/local/bin/python3.11 (found suitable version "3.11.2", minimum required is "3.4")
👀

Keep in mind that FindPythonInterp is deprecated: https://cmake.org/cmake/help/latest/module/FindPythonInterp.html

Build ran through, but verification at the end failed:
Error: Unsupported deployment target 11.6 found: build/OpenSCAD.app/Contents/MacOS/OpenSCAD

@t-paul not sure about that deployment target error, crossing fingers that it could be related to that MAC_OSX_VERSION_MIN mismatch I've now attempted to fix.

@kintel good shout re/ PythonInterp! Will try & address once this one works :-)

@ochafik I just opened a separate PR with a fix: #4573

FYI: The real issue was that cmake's project() function initialized CMAKE_OSX_DEPLOYMENT_TARGET to the current SDK and cached the value, so we need to get our override in before calling project().

btw., what is Python used for in this context?

@kintel not quite sure, maybe adding manifold as a submodule was altering the python-finding logic (I did try and disable some of its subdirectories with set(MANIFOLD_PYBIND OFF) etc, even enabled policy CMP0077 to allow that), so that when we did our find_package(Python3) in the openscad/resources subfolder it was hitting Python2 instead of PY3.

I've pushed PythonInterp out with the last commit btw.

Yeah, I see now. Direct inclusion of external libraries via cmake add_subdirectory() is a very scary thing, unless we can isolate the cmake run to avoid side effects. ..but that may be as much work as integrating Manifold in the first place..

Golden rule of multi-platform software engineering: Making software build and run is harder than writing software in the first place : /

I'll make at attempt at root causing it, but it's extra scary since Manifold add_subdirectory() pybind11, so this may run pretty deep.

Here's the root cause: googletest looks for Python, prefers Python2 and leaks that state to our CMake environment:
https://github.com/google/googletest/blob/2fe3bd994b3189899d93f1d5a881e725e046fdc2/googletest/cmake/internal_utils.cmake#L239

Included from submodules/manifold/test/third_party/google_test/googletest/cmake/

Considering how liberally Manifold uses add_subdirectory(), I think the right fix here would be to build Manifold in isolation and write a FindManifold macro for including into OpenSCAD.

Anyway, I added a hack for now; just find our Python before someone else can find Python2 :) 62ca8bd

This is probably no longer needed after merging #4573