Apple specific hardware testing

[akielaries]

Lack of OSX related support for Apple's specific hardware.

• Pip wheels for Apples M1/M2 chips are not done by the CI/CD pipeline implemented. Instead, when running pip install openmtpk on an Apple hardware specific machine (Macbooks 2020+), SWIG is needed as a dependency to build the wheel from scratch. This isn't an issue but would be nice to offer more support for this.
• openMTPK's source API (C++) is also not tested on Apple specific hardware. This goes in hand with #27 where the build process on Apple computers hangs on the GoogleTest portion of the process.

[sidsbrmnn]

Hi @akielaries, can you provide more context on the SWIG dependency? The fix that I'm working is being tested on a M2 machine and so far I faced zero issues even without SWIG installed.

[akielaries]

Sure thing, however it may be time for me to test this out myself as it's been some time!

In the openmtpk github action under the compile_wheels job, PyPI pip wheels are built for OSX x86 machines but does not include support for building a wheel for OSX on the M1 or M2 chips.

When running pip install openmtpk the host machine looks for the most compatible wheel included in the package, if there isn't one there's an attempt to build one from scratch using setup.py located in the projects root directory which utilizes the SWIG interface files with .i extension located in the Python API directory.

I have limited access to M1 hardware, but from my experience I noticed since there wasn't an M1 wheel included in the PyPI package an attempt to create one with SWIG was being executed upon installation.

When running pip install openmtpk on your M2 machine, does it install a pip wheel and are you able to execute some of the samples located in the samples/python dir? I will also perform a test on this later when I get access to an M1 chip to test on.

[akielaries]

In the openmtpk PyPI package files here it appears support for aarch64 OSX machines is now included. Let me confirm this on the M1 and I'll reply with my results

[akielaries]

After trying this on M1 I confirmed that it indeed is trying to build the pip wheel from scratch and looks for SWIG as a dependency. Could you paste the output you get when running pip install openmtpk?

[sidsbrmnn]

$ pip install --no-cache openmtpk
Collecting openmtpk
  Downloading openmtpk-0.9.7-cp311-cp311-macosx_11_0_arm64.whl (189 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 189.3/189.3 kB 3.3 MB/s eta 0:00:00
Installing collected packages: openmtpk
Successfully installed openmtpk-0.9.7

When I do a pip install, I get a whl installed. It's not from source. I also notice that there's arm64 architecture mentioned for OSX compilation in the CI workflow. And yes, the scripts in samples/python run smoothly.

[sidsbrmnn]

Yup, I went through pypa/cibuildwheel and you're in fact building wheels for multiple platforms (including Apple Silicon). I forced build from source and yup, swig is a requirement... You're right.

In my opinion, easiest way to handle this is to add it to build requirements while installing from source. What is your take on this? As far as wheel builds are concerned, the pipeline seems to be in good shape for any architecture on demand.

[akielaries]

Thank you for pasting your output! This is very interesting I'll definitely need to test this on my machines.

So my only thoughts on improving this are sort of a pain and possibly a stretch. The current pipeline makes use of some 3rd party Github Actions, Docker, as well as QEMU to build & test the wheels for these platforms. I am thinking, if it is possible, to get an OSX M1 Docker/QEMU image to plug into this process. This wouldn't be to create the wheel but instead be apart of the post-PyPI upload tests that perform a pip install on the recently uploaded version and run the samples for Python that way we can test on OSX for M1 and M2. These post-upload tests are located here

Also feel free to reach out in any way if you'd like to brainstorm some possible solutions for this.

[akielaries]

❯ g++-12 mtx.cpp -I/usr/local/include/ -L/usr/local/lib

  "__ZN4gpmp6linalg3Mtx11mtx_add_f90EPfS2_S2_m", referenced from:
      __Z11mtx_add_f90v in ccWB5MUw.o
  "__ZN4gpmp6linalg3Mtx11std_mtx_addIdEEvRKSt6vectorIS3_IT_SaIS4_EESaIS6_EESA_RS8_", referenced from:
      __Z16run_mtx_add_doubv in ccWB5MUw.o
  "__ZN4gpmp6linalg3Mtx11std_mtx_addIfEEvRKSt6vectorIS3_IT_SaIS4_EESaIS6_EESA_RS8_", referenced from:
      __Z15run_mtx_add_fltv in ccWB5MUw.o
  "__ZN4gpmp6linalg3Mtx11std_mtx_addIiEEvPKT_S5_PS3_ii", referenced from:
      __Z15run_mtx_add_arrv in ccWB5MUw.o
  "__ZN4gpmp6linalg3Mtx11std_mtx_addIiEEvRKSt6vectorIS3_IT_SaIS4_EESaIS6_EESA_RS8_", referenced from:
      __Z11run_mtx_addv in ccWB5MUw.o
  "__ZN4gpmp6linalg3Mtx7mtx_addEPKiS3_Piii", referenced from:
      __Z15run_mtx_add_arrv in ccWB5MUw.o
  "__ZN4gpmp6linalg3Mtx7mtx_addERKSt6vectorIS2_IdSaIdEESaIS4_EES8_RS6_", referenced from:
      __Z16run_mtx_add_doubv in ccWB5MUw.o
  "__ZN4gpmp6linalg3Mtx7mtx_addERKSt6vectorIS2_IfSaIfEESaIS4_EES8_RS6_", referenced from:
      __Z15run_mtx_add_fltv in ccWB5MUw.o
  "__ZN4gpmp6linalg3Mtx7mtx_addERKSt6vectorIS2_IiSaIiEESaIS4_EES8_RS6_", referenced from:
      __Z11run_mtx_addv in ccWB5MUw.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

will need to dig into this error produced on OSX