Document microarchitecture-optimized builds

[jaimergp]

PR Checklist:

• note any issues closed by this PR with closing keywords
• if you are adding a new page under docs/, you have added it to the sidebar in docs/sidebar.json
• put any other relevant information below
• Comes from Add microarch-level packages staged-recipes#24306 (comment)

We talked about this in today's conda community meeting so let's get add it to the shiny docs :D Preview link: https://deploy-preview-2091--conda-forge-previews.netlify.app/docs/maintainer/knowledge_base/#microarch

cc @mbargull

[netlify]

✅ Deploy Preview for conda-forge-previews ready!

Name	Link
🔨 Latest commit	e496664
🔍 Latest deploy log	https://app.netlify.com/sites/conda-forge-previews/deploys/65dfa569fa3af4000810b73d
😎 Deploy Preview	https://deploy-preview-2091--conda-forge-previews.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[beckermr]

Huzzah!

[traversaro]

Sorry, a bit late to the part. In https://github.com/conda-forge/microarch-level-feedstock it is written:

The run_exports only has a lower bound and therefore a level=2 build can be installed on a level=3 user system. A tighter bound is not added because we want to be able to test both level=2 and level=3 on a CI machine with level=3. Therefore in order to prioritise the highest level, use the build number to prioritise the level.

So the example should also include the logic to increase the build number of packages with higher level?

[h-vetinari]

Actually, the very recent archspec 0.2.3 now has windows support, in large part due to @isuruf's work on this. 🥳

Not sure what else is necessary to wire this up though, just tried on a fully up-to-date environment:

>conda info
    [...]
       virtual packages : __archspec=1=x86_64
                          __conda=24.1.2=0
                          __win=0=0

[stuarteberg]

We ran into a strange bug when we recently used this feature to add microarch-optimized builds to the graph-tool feedstock (via conda-forge/graph-tool-feedstock#140).

This didn't work for us:

microarch_level:  # [unix and x86_64]
  - 1  # [unix and x86_64]
  - 3  # [unix and x86_64]
  - 4  # [unix and x86_64]

...because, weirdly, NON-x86 builds (such as linux_aarch64) were being given a microarch_level environment variable!! (It was set as microarch_level=4.) As far as I can tell, the only explanation is that conda-build has a bug. The relevant files in .ci_support for the non-x86 variants made no mention whatsoever of microarch_level. It should not have had a value at all since the selectors excluded it for those variants.

Fortunately, there was an easy workaround: Always list at least one microarch_level, regardless of the target CPU.

microarch_level:
  - 1
  - 3  # [unix and x86_64]
  - 4  # [unix and x86_64]

Should we modify the conda-forge docs to match? (I have not filed a bug report with conda-build because it will presumably be somewhat time-consuming to produce a minimal example.)

[jaimergp]

A PR is always welcome! Maybe a note with the "gotcha" is enough:

:::note

In non x86 architectures...

:::

[mbargull]

As far as I can tell, the only explanation is that conda-build has a bug.

It is probably not a bug, but the (IMO, unfortunate) feature of conda-build in that it searches for uses of environment variable corresponding to the variant entries in build scripts and thus considers microarch_level as a "used" due to the ${microarch_level} in your script.
It might suffice to just say ${microarch_level:-1} instead in the build script to avoid it.