search

pthom / imgui_bundle

Your fast track to powerful GUIs: Dear ImGui Bundle, an extensive toolkit for Python and C++ with immediate mode efficiency.
https://pthom.github.io/imgui_bundle/
MIT License
694 stars 72 forks source link

macos deployment target #80

Closed dcnieho closed 1 year ago

dcnieho commented 1 year ago

Despite your pyproject.toml listing 11.0 as a deployment target, the arm64 (but not the x86_64) wheels for 3.10 and 3.9 seem to have 13.0 as deployment target, see here: https://pypi.org/project/imgui-bundle/#files. That is causing trouble for some of my users who are on an M1, its a pretty high requirement to reach. Is it possible to correct that?

dcnieho commented 1 year ago

Hmm, i have another M1 Mac user who (without xcode installed) had no problem a while ago. The WHEEL file in their imgui_bundle-0.8.2.dist-info lists this:

Wheel-Version: 1.0 Generator: skbuild 0.16.6 Root-Is-Purelib: false Tag: cp310-cp310-macosx_10_16_x86_64

which surprises me. Apparently they run through rosetta: sysconfig.get_platform() 'macosx-10.9-x86_64' sysconfig.get_config_vars()['HOST_GNU_TYPE'] 'x86_64-apple-darwin13.4.0'

Thats fine, but what surprises me is that they have a macosx_10_16 wheel while whats on pypi for 0.8.2 is a macosx_11_0 wheel.

Whats the lowest deployment target you can get away with by the way? The lower the better is my understand, because the more compatible.

dcnieho commented 1 year ago

The other user now managed to install after installing xcode (compile failed since they didn't have it, xcrun not found). This is whats in the wheel file of the installed package: Wheel-Version: 1.0 Generator: skbuild 0.16.6 Root-Is-Purelib: false Tag: cp310-cp310-macosx_10_16_x86_64

sysconfig.get_platform() 'macosx-10.9-x86_64' sysconfig.get_config_vars()['HOST_GNU_TYPE'] 'x86_64-apple-darwin13.4.0'

So same as the other guy for which it did work

pthom commented 1 year ago

I'm sorry I'm on holiday, and do not have much time for this. Some details: the mac wheels are built by cibuildwheel.

For x86_64, they are built on github. For ARM, I cannot trust github builders since they are running on Intel Mac and a dependency on Intel IPP is added even if they are trying to build for ARM.

So I have to build them on my own mac. I build them with cibuildwheel also, and I just replace archs = ["arm64"] inside pyproject.toml

So the build should be targeting 11.0, since pyproject mentions: MACOSX_DEPLOYMENT_TARGET="11.0"

And this is what I see during the build:

image

However, near the end, I can read an unhelpful message in the build log:

  [WARNING] This wheel needs a higher macOS version than is set in MACOSX_DEPLOYMENT_TARGET variable.  To silence this warning, set MACOSX_DEPLOYMENT_TARGET to at least 13_0 or recreate these files with lower MACOSX_DEPLOYMENT_TARGET:
  _skbuild/macosx-11.0-arm64-3.9/setuptools/bdist.macosx-11.0-arm64/wheel/imgui_bundle/_imgui_bundle.cpython-311-darwin.so[WARNING] This wheel needs a higher macOS version than is set in MACOSX_DEPLOYMENT_TARGET variable.  To silence this warning, set MACOSX_DEPLOYMENT_TARGET to at least 13_0 or recreate these files with lower MACOSX_DEPLOYMENT_TARGET:
  _skbuild/macosx-11.0-arm64-3.9/setuptools/bdist.macosx-11.0-arm64/wheel/imgui_bundle/_imgui_bundle.cpython-311-darwin.socreating _skbuild/macosx-11.0-arm64-3.9/setuptools/bdist.macosx-11.0-arm64/wheel/imgui_bundle-0.8.3.dist-info/WHEEL
  creating '/private/var/folders/w1/w77kvvl9613022ksfxj7v8xh0000gn/T/pip-wheel-2w3mmnbn/.tmp-p0oakfmp/imgui_bundle-0.8.3-cp39-cp39-macosx_13_0_arm64.whl' and adding '_skbuild/macosx-11.0-arm64-3.9/setuptools/bdist.macosx-11.0-arm64/wheel' to it

Attached are the full logs:

cib_err.txt cib_log.txt

dcnieho commented 1 year ago

Enjoy your holiday! No rush!

I do see -DCMAKE_OSX_DEPLOYMENT_TARGET=11.0 in the command lines, i am not sure what that acts on though.

Maybe its the OpenCV? Have you tried specifying -mmacosx-version-min=11 for the compiler command lines? How have you chosen 11.0 by the way? The lower the better I think, as long as the compiler toolchain still supports what you need. It seems 10.9 is common, for my own project i had to use 10.14 due to need for c++17 features (if i recall correctly, thats the first version where those are properly supported).

pthom commented 1 year ago

Closing this, as I cannot reproduce it, and it was probably solved in the next releases. Please reopen if still present.

dcnieho commented 5 months ago

@pthom I cannot reopen, but this issue persists. I have a user on OSX 13.4.1 on an M1 pro for who the wheel gets compiled through xcode when trying to install imgui_bundle. For students of this user who do not have xcode, the install fails completely (of course).

I asked the user to give me some info about their environment. The potentially relevant bit of pip inspect > inspect.json is:

  "environment": {
    "implementation_name": "cpython",
    "implementation_version": "3.11.7",
    "os_name": "posix",
    "platform_machine": "x86_64",
    "platform_release": "22.5.0",
    "platform_system": "Darwin",
    "platform_version": "Darwin Kernel Version 22.5.0: Thu Jun  8 22:22:20 PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T6000",
    "python_full_version": "3.11.7",
    "platform_python_implementation": "CPython",
    "python_version": "3.11",
    "sys_platform": "darwin"
  }

A selection of what pip debug --verbose gives us:

pip version: pip 23.3.1 from /opt/anaconda3/envs/testvoorDied/lib/python3.11/site-packages/pip (python 3.11)
sys.version: 3.11.7 (main, Dec 15 2023, 12:09:04) [Clang 14.0.6 ]
sys.executable: /opt/anaconda3/envs/testvoorDied/bin/python
sys.getdefaultencoding: utf-8
sys.getfilesystemencoding: utf-8
locale.getpreferredencoding: UTF-8
sys.platform: darwin
sys.implementation:
  name: cpython
'cert' config value: Not specified
REQUESTS_CA_BUNDLE: None
CURL_CA_BUNDLE: None
pip._vendor.certifi.where(): /opt/anaconda3/envs/testvoorDied/lib/python3.11/site-packages/pip/_vendor/certifi/cacert.pem
pip._vendor.DEBUNDLED: False
vendored library versions:
[...]
Compatible tags: 1964
  cp311-cp311-macosx_10_16_x86_64
  cp311-cp311-macosx_10_16_intel
  cp311-cp311-macosx_10_16_fat64
  cp311-cp311-macosx_10_16_fat32
  cp311-cp311-macosx_10_16_universal2
  cp311-cp311-macosx_10_16_universal
[...]
  cp311-abi3-macosx_10_16_x86_64
  cp311-abi3-macosx_10_16_intel
  cp311-abi3-macosx_10_16_fat64
  cp311-abi3-macosx_10_16_fat32
  cp311-abi3-macosx_10_16_universal2
  cp311-abi3-macosx_10_16_universal
[...]
  cp311-none-macosx_10_16_x86_64
  cp311-none-macosx_10_16_intel
  cp311-none-macosx_10_16_fat64
  cp311-none-macosx_10_16_fat32
  cp311-none-macosx_10_16_universal2
  cp311-none-macosx_10_16_universal
[...]
  cp310-abi3-macosx_10_16_x86_64
  cp310-abi3-macosx_10_16_intel
  cp310-abi3-macosx_10_16_fat64
  cp310-abi3-macosx_10_16_fat32
  cp310-abi3-macosx_10_16_universal2
  cp310-abi3-macosx_10_16_universal
[...]
  cp39-abi3-macosx_10_16_x86_64
  cp39-abi3-macosx_10_16_intel
  cp39-abi3-macosx_10_16_fat64
  cp39-abi3-macosx_10_16_fat32
  cp39-abi3-macosx_10_16_universal2
  cp39-abi3-macosx_10_16_universal
[...]
  py311-none-macosx_10_16_x86_64
  py311-none-macosx_10_16_intel
  py311-none-macosx_10_16_fat64
  py311-none-macosx_10_16_fat32
  py311-none-macosx_10_16_universal2
  py311-none-macosx_10_16_universal
[...]
  py3-none-macosx_10_16_x86_64
  py3-none-macosx_10_16_intel
  py3-none-macosx_10_16_fat64
  py3-none-macosx_10_16_fat32
  py3-none-macosx_10_16_universal2
  py3-none-macosx_10_16_universal
[...]
  cp311-none-any
  py311-none-any
  py3-none-any
  py310-none-any
  py39-none-any
  py38-none-any
  py37-none-any
  py36-none-any
  py35-none-any
  py34-none-any
  py33-none-any
  py32-none-any
  py31-none-any
  py30-none-any

and a whole bunch of variations with lower Python versions and lower deployment targets (10_15, etc).

The problem is that your packages on pypi are imgui_bundle-1.3.0-cp311-cp311-macosx_11_0_x86_64.whl and imgui_bundle-1.3.0-cp311-cp311-macosx_11_0_arm64.whl, in other words, they target a higher deployment targets than this user (and a bunch more) have.

Compared to our discussion from before, i see that your wheels now target 11.0 at least, instead of 13.0. But thats still too high.

Could you try specifying 10.14? I am pointing out that one as some code i have that uses pretty new C++ features compiles and bundles fine with MACOSX_DEPLOYMENT_TARGET: 10.14 in my github runner, and the lower the better (the more compatible).

dcnieho commented 5 months ago

So that's the following locations where you could set 10.14 instead of 11.0: https://github.com/pthom/imgui_bundle/blob/670c72e0cab1beaa4a5761861286dd3f871b4ead/pyproject.toml#L83 https://github.com/pthom/imgui_bundle/blob/670c72e0cab1beaa4a5761861286dd3f871b4ead/.github/workflows/pip.yml#L9 https://github.com/pthom/imgui_bundle/blob/670c72e0cab1beaa4a5761861286dd3f871b4ead/.github/workflows/cpp_lib.yml#L10 https://github.com/pthom/imgui_bundle/blob/670c72e0cab1beaa4a5761861286dd3f871b4ead/.github/workflows/cpp_lib_with_bindings.yml#L10