Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename MACOS_DEPLOYMENT_TARGET back to MACOSX_DEPLOYMENT_TARGET #309

Merged
merged 2 commits into from
Feb 15, 2023

Conversation

stefanv
Copy link
Contributor

@stefanv stefanv commented Feb 15, 2023

This is the environment variable name used by Apple (see compat(5)). It is also supported by cibuildwheel, CMAKE, etc.

It was renamed in 9e84bd9

Closes pypa/cibuildwheel#1419

@stefanv
Copy link
Contributor Author

stefanv commented Feb 15, 2023

There is one other similar occurrence, which is MACOS_BUILD_TARGET, which occurs only in tests/test_tags.py.

@henryiii
Copy link
Contributor

Ideally, it would be nice to get this into a patch release, since it is a pretty bad regression that breaks the ability to make wheels for older macOS versions (unless you know to set MACOS_BUILD_TARGET as well as MACOSX_BUILD_TARGET :) ).

@dnicolodi
Copy link
Member

Ups, this typo is mine. I remember cross checking the variable name with the one used by other tools and convincing myself that all was good. I also tested this and it seemed to work fine, for example here https://github.com/dnicolodi/python-siphash24/actions/runs/3553666516/jobs/5969311668 cibuildwheel does not complain. Anyhow, the fix is obviously correct.

The MACOS_BUILD_TARGET thing in the tests is broken: the test does not test what it looks like it tests (setting this environment variable has no effect on the computed wheel tags but the test is broken). It is probably a left over from when the wheel tags where computed differently that I forgot to clean up. I'm having a look at what the story is there.

@dnicolodi
Copy link
Member

Nope, I added the broken MACOS_BUILD_TARGET test and I've looked everywhere, but it really seem to be something I made up. I think the test can be simply removed. Does anyone know how I could have come up with this environment variable name?

@dnicolodi
Copy link
Member

@stefanv I don't find anything about environment variables in the comapt man page on my macOS system with Xcode 14.2. Where did you find it documented?

@dnicolodi dnicolodi force-pushed the MACOSX_DEPLOYMENT_TARGET-restore branch from 7fc234c to f4cdce7 Compare February 15, 2023 16:32
The test tried to test the effect of setting the MACOS_BUILD_TARGET
environment variable on the produced wheel tags, however there is bug
for which the emitted tags are always compared to the tag for the
current platform. The environment variable has no effect on the wheel
tags. Remove the bogus test.
@dnicolodi dnicolodi force-pushed the MACOSX_DEPLOYMENT_TARGET-restore branch from f4cdce7 to af2432d Compare February 15, 2023 16:33
@dnicolodi dnicolodi merged commit 657747a into mesonbuild:main Feb 15, 2023
@stefanv
Copy link
Contributor Author

stefanv commented Feb 15, 2023

@stefanv I don't find anything about environment variables in the comapt man page on my macOS system with Xcode 14.2. Where did you find it documented?

Thanks for reviewing, @dnicolodi!

Here's the relevant manpage (I don't own a mac, so can't say exactly where this was captured):

https://www.manpagez.com/man/5/compat/

@Czaki
Copy link

Czaki commented Feb 15, 2023

The MACOS_BUILD_TARGET thing in the tests is broken

It was broken, because meson, in contrast to the wheel, does not check the platform tag in binary files, but only read values from the environment variable.

@jarrodmillman
Copy link

jarrodmillman commented Feb 15, 2023

Ideally, it would be nice to get this into a patch release, since it is a pretty bad regression that breaks the ability to make wheels for older macOS versions (unless you know to set MACOS_BUILD_TARGET as well as MACOSX_BUILD_TARGET :) ).

@henryiii @FFY00 A 0.13.0rc1 release would be great, since we are already using 0.13.0rc0 for scikit-image.

@dnicolodi
Copy link
Member

The MACOS_BUILD_TARGET thing in the tests is broken

It was broken, because meson, in contrast to the wheel, does not check the platform tag in binary files, but only read values from the environment variable.

Would you like to elaborate? Meson is not responsible for generating Python wheels. Also, which piece of software react to the MACOS_BUILD_TARGET environment variable? I haven't found any. meson-python only checks the MACOSX_DEPLOYMENT_TARGET to produce the wheel tags as it trusts the fact that if the environment variable is set, the toolchain has done the right thing and build a binary compatible with the specified macOS version. I don't see where MACOS_BUILD_TARGET enters in this process.

@dnicolodi
Copy link
Member

Here's the relevant manpage (I don't own a mac, so can't say exactly where this was captured):

https://www.manpagez.com/man/5/compat/

Thanks. The linked man page is the same as the one on my system. I just overlooked the mention of the MACOSX_DEPLOYMENT_TARGET environment variable in it.

@Czaki
Copy link

Czaki commented Feb 15, 2023

The test that was removed in this PR and does not fails even if a typo in the variable because there is no validation if files are created correctly.

I do not play with meson, but when using another build system, it happens to have build polluted by the previous run (ex. make, cmake will not rebuild all files because the env variable is changed, only this that sources files were changed) or part of build process may be the usage of binary blob give by a vendor (like in this package https://github.com/tlambert03/nd2).

Both scenarios will lead to an incorrectly tagged wheel file. First may be minimalized by using CI, but still user could enable cache operations for speedup build.

@dnicolodi
Copy link
Member

The test that was removed in this PR and does not fails even if a typo in the variable because there is no validation if files are created correctly.

This is not what was wrong with the test. The typo was in an environment variable name not touched by the removed test.


@pytest.mark.skipif(platform.system() != 'Darwin', reason='macOS specific test')
def test_tag_macos_build_target(monkeypatch):
monkeypatch.setenv('MACOS_BUILD_TARGET', '12.0')
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see here that is touched

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, but who reads it? Which piece of software reads this environment variable? The environment variable expected by the toolchain is MACOSX_DEPLOYMENT_TARGET. I suspect that MACOS_BUILD_TARGET is something I made up.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. but when this test will set variable to 10.9 and the tag calculation will check files then this test will fail, as the test will in both runs return 12.0 (as the wrong variable was set).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Czaki you don't make any sense. I'm giving up.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your assumption that after correctly setting the environment variable, the toolchain will produce the correct files is wrong. It will often be true, but not always.

Nad I only point the test that, if checking the platform tag will examine files, the test will find a bug in the variable name.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Except that the test is not compiling any code an there is no file to examine.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After reading the code I was pretty sure that it compile. I'm sorry for bothering you.

jarrodmillman pushed a commit to jarrodmillman/scikit-image that referenced this pull request Feb 17, 2023
Change CI MACOSX_DEPLOYMENT_TARGET from 10.13 to 10.9 to allow for continued compatibility with earlier OS versions given that associated wheels are available which meet the dependency version requirements.

The correct fix for building MacOSX wheels is here:
mesonbuild/meson-python#309

We are using this temporary workaround:
scikit-image#6757

SciPy 1.10.1 will also suport 10.9:
scikit-image#6750
jarrodmillman pushed a commit to scikit-image/scikit-image that referenced this pull request Feb 17, 2023
Change CI MACOSX_DEPLOYMENT_TARGET from 10.13 to 10.9 to allow for continued compatibility with earlier OS versions given that associated wheels are available which meet the dependency version requirements.

The correct fix for building MacOSX wheels is here:
mesonbuild/meson-python#309

We are using this temporary workaround:
#6757

SciPy 1.10.1 will also suport 10.9:
#6750
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

macosx x86_64 build does not respect MACOSX_DEPLOYMENT_TARGET
6 participants