When developing a C++ project that cross-compiles from linux-64 to linux-aarch64, there is currently no way to have pixi install the target architecture's dependencies into a local persistent environment (e.g. .pixi/envs/aarch64) on the host machine.
In order to cross-compile (and have full control over it), I'd require the target libraries to be present on the host machine so that the cross-compiler can link against them.
It'd be nice to have an option that forces Pixi to unpack the foreign-arch packages locally regardless of the host platform.
Something similar was suggested in #5389 (comment) , proposing what I consider a viable and clean solution.
Also, the same issue was pointed out in #3457, and the proposed solution was to use Pixi build, however this would reduce flexibility.
I reckon the problem can be addressed by simply introducing a flag pixi install --platform linux-aarch64.
Are you planning to introduce such a feature? If needed, I'm also open to working on that, if that's something you might be interested in.
Moreover, do you have any workaround that achieves what I described?
When developing a C++ project that cross-compiles from
linux-64tolinux-aarch64, there is currently no way to have pixi install the target architecture's dependencies into a local persistent environment (e.g. .pixi/envs/aarch64) on the host machine.In order to cross-compile (and have full control over it), I'd require the target libraries to be present on the host machine so that the cross-compiler can link against them.
It'd be nice to have an option that forces Pixi to unpack the foreign-arch packages locally regardless of the host platform.
Something similar was suggested in #5389 (comment) , proposing what I consider a viable and clean solution.
Also, the same issue was pointed out in #3457, and the proposed solution was to use Pixi build, however this would reduce flexibility.
I reckon the problem can be addressed by simply introducing a flag
pixi install --platform linux-aarch64.Are you planning to introduce such a feature? If needed, I'm also open to working on that, if that's something you might be interested in.
Moreover, do you have any workaround that achieves what I described?