-
-
Notifications
You must be signed in to change notification settings - Fork 12
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
Disable cross compiling for POWER architecture #47
Conversation
We suspect that the emulated (as opposed to native) builds may be causing the tests to fail for these architectures. This commit tries to bump the conda-forge builds back to native hosts instead of cross-compiling. PyWavelets/pywt#607
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
@conda-forge-admin, please rerender |
…nda-forge-pinning 2021.11.17.15.51.01
ARM can't be moved ( conda-forge/conda-forge.github.io#1555 ) Edit: Though we already have it configured to emulate anyways. |
In theory, setting a provider for osx_arm64 should cause that architecture to be built, but due to the drone.io outage we need to force cross-compilation on another platform. We also need to force compilation of linux_ppc64le natively because tests fail when emulated.
…nda-forge-pinning 2021.11.17.15.51.01
Looks like cross-compiling was the problem! Will mark ready for review once all the builds are green. |
conda-forge.yml
Outdated
linux_aarch64: linux_64 | ||
linux_ppc64le: linux_64 | ||
osx_arm64: osx_64 | ||
linux_ppc64le: linux_ppc64le # tests fail when emulating power from x86 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think this can just be default
since we build natively there
linux_ppc64le: linux_ppc64le # tests fail when emulating power from x86 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I explicitly choose linux_ppc64le
because we know that the build doesn't work when emulated. The default could be changed to linux_64
like it was for linux_aarch64, then this build would break again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, It only renders with linux_ppc64le
. I cannot use the default
key here; it causes the following error:
File "/home/dching/miniconda3/envs/forge/lib/python3.9/site-packages/conda_smithy/configure_feedstock.py", line 947, in _get_platforms_of_provider
build_platform, build_arch = build_platform_arch.split("_")
ValueError: not enough values to unpack (expected 2, got 1)
Seems like the build platform is expected to be an explicit platform if defined.
These linux ARM builds have been running for more than 2.5 hours! 😟 |
conda-forge.yml
Outdated
osx_arm64: osx_64 | ||
conda_forge_output_validation: true | ||
provider: | ||
linux_aarch64: default | ||
linux_aarch64: travis |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no ARM support on Travis. We are stuck emulating them on Azure. Yes it does take a while unfortunately.
Please see PR ( conda-forge/conda-forge.github.io#1555 )
LGTM, happy if it works! Random question: PRs on feedstocks are always a pain to review, because the regular diff view is mostly changes from re-rendering. Is there any guidance or best practice around this, like one should be squashing history to 1-2 commits with changes, and one re-rendering commit? And then one can review the commit diff? |
Usually I just click on the commits tab to see the non-rerendering ones individually. In most cases there are only a small number, so that works out okay. |
I believe only the files in the recipe folder and conda-forge.yml control the rendering (are managed by humans or bots), so I look at those. |
Btw, can you check if using |
We hide some files with |
This is a really good point! Have seen similar things with VMs (like VirtualBox) where AVX and some versions of SSE instructions don't work. Though normally in that case different kernels without those instructions get selected as OpenBLAS determines they are not supported. What system calls did you have in mind? |
|
Maybe emulated builds of ppc64le are failing because the BLAS implemenation doesn't support emulation. conda-forge#47 (comment)
Adding |
FYI, I believe this PR is preventing the |
Or rather, merging this PR will unblock the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM for merging. Can this be squash-merged, or is it needed/useful to rewrite into a single commit with functional changes and one other commit to re-render?
It's useful to see the commits from re-rendering on the non-recipe files in case there is an issue we need to dig into later |
I agree w/ @jakirkham but there is no reason to change things now. Let's go ahead and merge. |
We suspect that the emulated (as opposed to native) builds may be causing the tests to fail for these architectures. This commit tries to bump the conda-forge builds back to native hosts instead of cross-compiling.
Closes PyWavelets/pywt#607
Checklist
0
(if the version changed)conda-smithy
(Use the phrase@conda-forge-admin, please rerender
in a comment in this PR for automated rerendering)