conda-forge / conda-forge/conda-forge.github.io

Flags in compiler activation vs. out-of-conda-forge usage

Open
#2,002 3 comments 9 reactions 0 assignees View on GitHub
Dominant language
JavaScript
Stars
170
Forks
320
Avg merge
2d 10h
Merged PRs (30d)
5

Description

Part of the success of conda-forge is that many upstream projects have adopted (or at least support) development environments based on conda-forge packages. Almost inevitably, this ends up pulling in compilers as well - either through the explicit `compilers` package, or through other means (like directly depending on `gcc_linux-64` or `clang_osx-64`).

This runs into the [question](https://github.com/conda-forge/conda-forge.github.io/issues/1998) whether this is something we can or want to support. The status quo following Hyrum's law is of course that they're being used in several ways.

This "off-label" compiler use then runs into issues, like that the flags we inject into our compiler activation create problems for development. Anything from `-DNDEBUG` / `-O2`, etc. etc., see:
* https://github.com/conda-forge/ctng-compiler-activation-feedstock/issues/80
* https://github.com/conda-forge/ctng-compiler-activation-feedstock/issues/77
* https://github.com/conda-forge/ctng-compiler-activation-feedstock/issues/74
* https://github.com/conda-forge/ctng-compiler-activation-feedstock/issues/73
* https://github.com/conda-forge/ctng-compiler-activation-feedstock/issues/72
* https://github.com/conda-forge/ctng-compiler-activation-feedstock/issues/63
* https://github.com/conda-forge/ctng-compiler-activation-feedstock/issues/42
* https://github.com/conda-forge/clang-compiler-activation-feedstock/issues/90
* https://github.com/conda-forge/conda-forge.github.io/issues/1859
* https://github.com/conda-forge/conda-forge.github.io/issues/893

Latest [comment](https://github.com/conda-forge/meson-python-feedstock/pull/18#issuecomment-1706282133) to this effect:
> @rgommers: Polluting `CFLAGS` & co gives so many problems, isn't there an issue/plan somewhere to get rid of unnecessary flags and insert the desired ones for package building only inside `conda-build`/`mamba-build`?
>
> In this same release cycle we also already had to add [this warning](https://meson-python.readthedocs.io/en/latest/how-to-guides/debug-builds.html):
> image

Assuming we want to make our support explicit (for the usage of our compilers outside of conda-forge), we could potentially have both an internal & external compiler activation; the conda-forge internal one would add all the necessary flags (as now), and the external one would be reduced to a minimum.

Thoughts?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.