You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thank you for your interest in contributing to prefix.dev GmbH's Pixi GUI ("We" or "Us").
The purpose of this contributor agreement ("Agreement") is to clarify and document the rights granted by contributors to Us. To make this document effective, please follow the instructions at the link provided by the CLA bot in the Pull Request.
This document outlines a complete strategy to enable selectable debug and release build variants for packages built with pixi-build. The approach is rooted in a modular compiler architecture and is controlled by a custom build variant (profile) in the pixi.toml configuration.
This design centralizes the build configuration logic within the workspace, keeps individual recipe.yaml files clean and declarative, and guarantees ABI compatibility across the entire dependency tree.
Part 1: Foundational Components
Before the build tool can select variants, a modular package structure must exist. This involves separating the compiler toolchain into distinct components and creating special "token" packages to enforce build consistency.
Often the same package can be built in multiple ways.
Existing build systems typically call those ways profiles or build types.
For compiled languages that typically means different compiler flags and whether debug info is included or not.
Interpreted languages typically don't exactly expose profiles, the closest equivalent is --editable in the case of Python.
We want to empower users to define fine-grained profiles without too much effort or duplication.