conda-forge / conda-forge/conda-forge.github.io
Flags in compiler activation vs. out-of-conda-forge usage
- 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):
> 
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
Assessment
This issue has not been assessed yet.