Cross-compile linux-{aarch64,ppc64le}

[regro-cf-autotick-bot]

This PR has been triggered in an effort to update python312.

Notes and instructions for merging this PR:

1. Please merge the PR only after the tests have passed.
2. Feel free to push to the bot's branch to update this PR if needed.

Please note that if you close this PR we presume that the feedstock has been rebuilt, so if you are going to perform the rebuild yourself don't close this PR until the your rebuild has been merged.

---

If this PR was opened in error or needs to be updated please add the bot-rerun label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase @conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

_{This PR was created by the regro-cf-autotick-bot. The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. Feel free to drop us a line if there are any issues! This PR was generated by https://github.com/regro/cf-scripts/actions/runs/6377365503, please use this URL for debugging.}

[conda-forge-webservices]

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 (recipe) and found it was in an excellent condition.

[hmaarrfk]

my previous attempts found that things were creating the wrong so names:
it seems similar to the issue: gnuradio/gnuradio#5455 (comment)

[h-vetinari]

Yeah, cross-compiling with python is a mass of ducktape, string and prayers...

[hmaarrfk]

@conda-forge-admin please rerender

[h-vetinari]

In any case, we should cross-compile linux, because travis is essentially completely red on ppc (not in the PRs, but all the merges to main have so far managed to produce 2(!) passing runs out of >20)

[h-vetinari]

I noticed that the openimageio should be completely independent from python/numpy (both according to the link check, but also looking at the package content). IOW, it should be possible to make the build here do the lib only once and then the python bindings on top.

Also, it's quite "dirty" to have an output named the same as the feedstock, that's a fragile setup (e.g. tests on the output get ignored)... WDYT?

[hmaarrfk]

I noticed that the openimageio should be completely independent from python/numpy (both according to the link check, but also looking at the package content). IOW, it should be possible to make the build here do the lib only once and then the python bindings on top.

I'm not a fan of doing "special packaging work" when upstream doesn't make it clean to do so. Unfortunately, with the conda-machinery, it isn't too easy to pick and choose files. So I am inclined to just leave it as is. This is especially true when I am a passer-by on a recipe.

Also, it's quite "dirty" to have an output named the same as the feedstock, that's a fragile setup (e.g. tests on the output get ignored)... WDYT?

I'm not so sure about them getting ignored. But they do trigger special behavior.

[h-vetinari]

I'm not so sure about them getting ignored.

100% the case, it's a known issue.

I'm not a fan of doing "special packaging work" when upstream doesn't make it clean to do so.

Meh, it's just upstream being lazy and building everything in a bunch. I find it wasteful to rebuild the exact same library bits for X python versions when their content is exactly the same.

[h-vetinari]

Unfortunately, with the conda-machinery, it isn't too easy to pick and choose files.

I have a way to do this that's relatively low-effort. See e.g. boost or llvmdev. Idea is to install into a temporary prefix first, and then copy the files that one explicitly wants for an output into $PREFIX.

[h-vetinari]

If you want I can show you a draft on top of #88 (which we should rebase anyway once this PR is in).

[hmaarrfk]

Unfortunately, with the conda-machinery, it isn't too easy to pick and choose files.

I have a way to do this that's relatively low-effort. See e.g. boost or llvmdev. Idea is to install into a temporary prefix first, and then copy the files that one explicitly wants for an output into $PREFIX.

How does the python build-locally.py --debug command work. i can never select the subpackage correctly, or if i do, it doesn't activate in the right way.

It isn't so much about "getting it to work" but more about maintanance.

Things like conda-forge/opencv-feedstock#365 (and the history of the recipe) make me scared to push this kind of "advanced packaging" onto others.

[h-vetinari]

Still getting the wrong extension on aarch:

OpenImageIO.cpython-39-x86_64-linux-gnu.so

How does the python build-locally.py --debug command work. i can never select the subpackage correctly, or if i do, it doesn't activate in the right way.

I don't use that locally so much, but conceptually there's now a dependence on the global build step for (normally) all the outputs. So you have to do the global build.sh and then the script: per output (in order of the DAG).

Things like conda-forge/opencv-feedstock#365 (and the history of the recipe) make me scared to push this kind of "advanced packaging" onto others.

OpenCV is exceptionally complex in how the various bits interact with each other, which is why I deprioritized this. In other cases it's really very straight forward. "These bits go into this output, these bits go in the other output"

[hmaarrfk]

but conceptually there's now a dependence

Most, it fails at the environment activation step.

FWIW, the --debug command is what i'm using to make sure this is getting closer to correctness.

[hmaarrfk]

lets try in #88