Skip to main content

How to enable additional architectures

By default, feedstocks are created with support for the main platforms (e.g. linux-64, osx-64, win-64). Additional ones may be available in an opt-in fashion. The configuration can be changed manually in conda-forge.yml, or through automated migrations.

Automated migrations

New architectures can be added by changing the default configuration in conda-forge.yml and rerendering. However, since building a new architecture requires that your dependencies are also available for that architecture, this is usually controlled by migrations triggered by changes on specific files available in the conda-forge-pinning-feedstock repository.

Before submitting a build request for a new architecure, check whether:

  1. The package is already built for that architecture. Consult the package page in anaconda.org: https://anaconda.org/conda-forge/<package-name>.
  2. Your package is already in the process of being migrated in the corresponding migration status page.
  3. The feedstock in question has already an issue or pull request for that architecture, which may contain information why the package is not yet available.

If you do see an open PR (or once a PR is submitted by the migration), you can help the feedstock maintainers make the build pass. If you have insight into the particular package, please chime in, but most of all be patient and polite.

Once the new builds are available from anaconda.org, please help the maintainers by testing the packages, and reporting back with any problems… but also successes!

General steps

Adding a new architecture usually means following the same steps, but targeting different configuration files:

  1. Fork conda-forge-pinning-feedstock and create a fresh new branch. See How to fork your feedstock for more details.
  2. Edit the migration file for your architecture (see architecture-specific information) to add the name of your feedstock, without the -feedstock suffix. Make sure to insert it in the right position to respect alphabetical order, or run pre-commit run -a.
  3. Commit the changes, push the branch to your fork (origin) and open the pull request.
  4. Wait for a member of @conda-forge/core to review and merge your pull request.

Once merged, the feedstock will be added to the corresponding migration, which can be tracked in its status page (see architecture-specific information for the relevant links). When all dependencies are available, the bot will open a new PR with the necessary changes.

Architecture-specific information

The sections below specify the configuration details for each platform.

Enable osx-arm64

Note that this migration involves cross-compiled builds, which may get tricky if the build system has not been configured with those options in mind. Emulation is not available on this platform.

Enable linux-aarch64 and linux-ppc64le

Note that this migration will enable both architectures in your feedstock. If you only need one, you can push one of these changes to the bot PR:

  • Remove the corresponding line from conda-forge.yml and rerender.
  • Add a skip: directive to your recipe by matching the non-desired platform, and rerender.

This migration uses emulated builds by default, which are easier to configure but offer far worse performance. Cross-compiled builds requires extra configuration steps but it uses resources more efficiently (6-7x faster).

To change to cross-compiled builds, use this configuration in conda-forge.yml and rerender:

build_platform:
linux_aarch64: linux_64
linux_ppc64le: linux_64

Enable win-arm64

Manual migrations

note

Pending.